[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel

[jbeulich at novell dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21874

--- Comment #26 from Jan Beulich  ---
https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=eb0660c6950e08e44fdfeca3e29320382e2a1554
replaces the original commit.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel

[jbeulich at novell dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21874

--- Comment #25 from Jan Beulich  ---
(In reply to H.J. Lu from comment #24)
> Please don't do that.

Why would I not? As indicated, you didn't obtain maintainer approval. In fact
I've just checked the mailing list archives - you didn't even think you would
need to, as you've sent the mail (according to its subject) only after the
commit. The amount of trouble you give me elsewhere (largely defeating my
intention of improving the overall code, using time I could equally well spend
on other things), I don't see any reason at all why I shouldn't insist on
proper process here.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21874

--- Comment #24 from H.J. Lu  ---
(In reply to Jan Beulich from comment #23)
> (In reply to H.J. Lu from comment #22)
> > The MASM syntax expression parser supports -masm=intel.
> 
> How that? The compiler doesn't emit expressions, it does all the
> calculations and emits plain numbers. Are you perhaps mixing up expressions
> and things like "dword ptr" specifiers (which aren't themselves expressions)?
> 
> > At very minimum, a warning should be issued by default, which can be 
> > controlled
> > by
> > 
> > -moperand-check=[none|error|warning]
> 
> I can certainly arrange for that, albeit it's a waste of time (and may defer
> when I get to submit the replacement patch, while I'll surely revert the
> original one before the next release bets branched, unless you finally show

Please don't do that.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel

[jbeulich at novell dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21874

--- Comment #23 from Jan Beulich  ---
(In reply to H.J. Lu from comment #22)
> The MASM syntax expression parser supports -masm=intel.

How that? The compiler doesn't emit expressions, it does all the calculations
and emits plain numbers. Are you perhaps mixing up expressions and things like
"dword ptr" specifiers (which aren't themselves expressions)?

> At very minimum, a warning should be issued by default, which can be 
> controlled
> by
> 
> -moperand-check=[none|error|warning]

I can certainly arrange for that, albeit it's a waste of time (and may defer
when I get to submit the replacement patch, while I'll surely revert the
original one before the next release bets branched, unless you finally show
willingness to fix the regression you've introduced).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21874

--- Comment #22 from H.J. Lu  ---
(In reply to Jan Beulich from comment #21)
> (In reply to H.J. Lu from comment #20)
> > MASM is totally irrelevant here.
> 
> This is your opinion, which I don't share. Is this formally written down
> anywhere? Plus the presence of a MASM syntax expression parser pretty
> clearly contradicts this statement of yours.

As I said, the main purpose of gas is to serve GCC. The MASM syntax expression
parser supports -masm=intel.  But we don't pursue MASM compatibility by making
gas itself inconsistent.  At very minimum, a warning should be issued by
default,
which can be controlled by

-moperand-check=[none|error|warning]

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel

[jbeulich at novell dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21874

--- Comment #21 from Jan Beulich  ---
(In reply to H.J. Lu from comment #20)
> MASM is totally irrelevant here.

This is your opinion, which I don't share. Is this formally written down
anywhere? Plus the presence of a MASM syntax expression parser pretty clearly
contradicts this statement of yours.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21874

--- Comment #20 from H.J. Lu  ---
(In reply to Jan Beulich from comment #19)
> (In reply to H.J. Lu from comment #18)
> > (In reply to Jan Beulich from comment #17)
> > > This is a tentative patch which could replace the bad one. Only tested on
> > > 2.29.1 so far.
> > 
> > Does GCC behave the same with and without -asm=intel with your change?
> 
> As long as there's only a single segment override - of course. Obviously
> multiple (redundant) segment overrides would then be accepted again, as they
> should be. But as long as gcc cares, it should emit anything like that.

No, they should not by gas.  MASM is totally irrelevant here.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel

[jbeulich at novell dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21874

--- Comment #19 from Jan Beulich  ---
(In reply to H.J. Lu from comment #18)
> (In reply to Jan Beulich from comment #17)
> > This is a tentative patch which could replace the bad one. Only tested on
> > 2.29.1 so far.
> 
> Does GCC behave the same with and without -asm=intel with your change?

As long as there's only a single segment override - of course. Obviously
multiple (redundant) segment overrides would then be accepted again, as they
should be. But as long as gcc cares, it should emit anything like that.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21874

--- Comment #18 from H.J. Lu  ---
(In reply to Jan Beulich from comment #17)
> This is a tentative patch which could replace the bad one. Only tested on
> 2.29.1 so far.
> 

Does GCC behave the same with and without -asm=intel with your change?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel

[jbeulich at novell dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21874

--- Comment #17 from Jan Beulich  ---
This is a tentative patch which could replace the bad one. Only tested on
2.29.1 so far.

--- 2.29.1/gas/config/tc-i386-intel.c
+++ 2.29.1/gas/config/tc-i386-intel.c
@@ -411,7 +413,19 @@ static int i386_intel_simplify (expressi
   intel_state.index))
return 0;
   if (!intel_state.in_offset)
-   intel_state.seg = e->X_add_symbol;
+   {
+ if (!intel_state.seg)
+   intel_state.seg = e->X_add_symbol;
+ else
+   {
+ expressionS exp;
+
+ exp.X_op = O_full_ptr;
+ exp.X_add_symbol = e->X_add_symbol;
+ exp.X_op_symbol = intel_state.seg;
+ intel_state.seg = make_expr_symbol ();
+   }
+   }
   i386_intel_fold (e, e->X_op_symbol);
   break;

@@ -935,7 +964,8 @@ i386_intel_operand (char *operand_string
  for (;;)
{
  expP = symbol_get_value_expression (intel_state.seg);
- if (expP->X_op != O_full_ptr)
+ if (expP->X_op != O_full_ptr 
+ || symbol_get_value_expression (expP->X_op_symbol)->X_op !=
O_register)
break;
  intel_state.seg = expP->X_add_symbol;
}
--- 2.29.1/gas/testsuite/gas/i386/inval-seg.l
+++ 2.29.1/gas/testsuite/gas/i386/inval-seg.l
@@ -1,10 +1,22 @@
 .*: Assembler messages:
 .*:3: Error: .*
 .*:4: Error: .*
+.*:7: Error: .*
+.*:8: Error: .*
+.*:9: Error: .*
+.*:10: Error: .*
+.*:11: Error: .*
 GAS LISTING .*


-   1 [ ]*  .text
-   2 [ ]*# All the following should be illegal
-   3 [ ]*  movl%ds,\(%eax\)
-   4 [ ]*  movl\(%eax\),%ds
+[  ]*[1-9][0-9]*[  ]*\.text
+[  ]*[1-9][0-9]*[  ]*# All the following should be illegal
+[  ]*[1-9][0-9]*[  ]*movl  %ds,\(%eax\)
+[  ]*[1-9][0-9]*[  ]*movl  \(%eax\),%ds
+[  ]*[1-9][0-9]*[  ]*
+[  ]*[1-9][0-9]*[  ]*\.intel_syntax noprefix
+[  ]*[1-9][0-9]*[  ]*mov   eax, es:foo:\[eax\]
+[  ]*[1-9][0-9]*[  ]*mov   eax, es:fs:foo:\[eax\]
+[  ]*[1-9][0-9]*[  ]*mov   eax, fs:foo:bar:\[eax\]
+[  ]*[1-9][0-9]*[  ]*mov   eax, fs:foo:gs:\[eax\]
+[  ]*[1-9][0-9]*[  ]*mov   eax, bar:gs:\[eax\]
--- 2.29.1/gas/testsuite/gas/i386/inval-seg.s
+++ 2.29.1/gas/testsuite/gas/i386/inval-seg.s
@@ -2,3 +2,10 @@
 # All the following should be illegal
movl%ds,(%eax)
movl(%eax),%ds
+
+   .intel_syntax noprefix
+   mov eax, es:foo:[eax]
+   mov eax, es:fs:foo:[eax]
+   mov eax, fs:foo:bar:[eax]
+   mov eax, fs:foo:gs:[eax]
+   mov eax, bar:gs:[eax]

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21874

--- Comment #16 from H.J. Lu  ---
(In reply to Jan Beulich from comment #15)
> (In reply to H.J. Lu from comment #12)
> > (In reply to Jan Beulich from comment #11)
> > > (In reply to H.J. Lu from comment #10)
> > > > Do you have a real example?
> > > 
> > > No, I don't. But I don't assume you have a real example of someone having
> > > used something like fs:foo:[ebx] either, to support your original change.
> > > The reporter's example, as he states, did not result in bad code being
> > > generated (and for that case accepting the code was the intended 
> > > behavior).
> > 
> > Someone bothered enough to open a bug report with a testcase.  That is
> > good enough for me.
>
> The mere fact that there was a loop that you've eliminated should already
> have given enough of a hint to you that at least certain redundant segment
> overrides were indeed intended to be permitted. Once again, I'm perfectly
> fine with invalid code (gs:foo:[mem]) to be properly rejected. I continue to
> consider gs:fs:[mem] valid code, based on MASM accepting it (for whatever,
> perhaps historical, reason).

MASM compatibility isn't the goal for gas.  The primary purpose of gas is
to support GCC.  Gas should behave the same with or without -asm=intel.
If it means that gs:fs:[mem] is invalid, so be it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel

[jbeulich at novell dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21874

--- Comment #15 from Jan Beulich  ---
(In reply to H.J. Lu from comment #12)
> (In reply to Jan Beulich from comment #11)
> > (In reply to H.J. Lu from comment #10)
> > > Do you have a real example?
> > 
> > No, I don't. But I don't assume you have a real example of someone having
> > used something like fs:foo:[ebx] either, to support your original change.
> > The reporter's example, as he states, did not result in bad code being
> > generated (and for that case accepting the code was the intended behavior).
> 
> Someone bothered enough to open a bug report with a testcase.  That is
> good enough for me.

Do you realize that this doesn't address my comment at all? Someone _claiming_
that an example provided is bad doesn't mean it is bad, the more when the
generated code is still matching expectations. If I was to follow what you say,
me claiming "fs:gs:[mem]" being rejected now breaks code I'm using somewhere
would be "good enough" for you. And really that's what I did (albeit openly
admitting that I have no actual use case, but I could easily construct one),
yet you continue to refuse fixing your earlier change.

The mere fact that there was a loop that you've eliminated should already have
given enough of a hint to you that at least certain redundant segment overrides
were indeed intended to be permitted. Once again, I'm perfectly fine with
invalid code (gs:foo:[mem]) to be properly rejected. I continue to consider
gs:fs:[mem] valid code, based on MASM accepting it (for whatever, perhaps
historical, reason).

Hence, as before, I only see two options here: You fix your change, or I revert
it and provide a fix which I consider correct (once I find time for doing so).
I think there's little point in me repeating this yet another time, should you
continue to reply back with unconvincing arguments.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel

[ubizjak at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21874

--- Comment #14 from Uros Bizjak  ---
(In reply to Uros Bizjak from comment #13)
> (In reply to H.J. Lu from comment #12)
>  
> > Someone bothered enough to open a bug report with a testcase.  That is
> > good enough for me.
> 
> gcc generated non-sensical output in -asm=intel mode, and assembler failed
> to detect obvious error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81641

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel

[ubizjak at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21874

--- Comment #13 from Uros Bizjak  ---
(In reply to H.J. Lu from comment #12)

> Someone bothered enough to open a bug report with a testcase.  That is
> good enough for me.

gcc generated non-sensical output in -asm=intel mode, and assembler failed to
detect obvious error.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21874

--- Comment #12 from H.J. Lu  ---
(In reply to Jan Beulich from comment #11)
> (In reply to H.J. Lu from comment #10)
> > > > In the case of "fs:gs:[eax]", you can replace it with
> > > > "fs:[eax]" to get the same output.
> > > 
> > > In straight line code yes. But what if a first override is hidden deep in 
> > > a
> > > macro you can't or don't want to modify, but you need to add an override 
> > > to
> > > in one special case?
> > 
> > Do you have a real example?
> 
> No, I don't. But I don't assume you have a real example of someone having
> used something like fs:foo:[ebx] either, to support your original change.
> The reporter's example, as he states, did not result in bad code being
> generated (and for that case accepting the code was the intended behavior).

Someone bothered enough to open a bug report with a testcase.  That is
good enough for me.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel

[jbeulich at novell dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21874

--- Comment #11 from Jan Beulich  ---
(In reply to H.J. Lu from comment #10)
> > > In the case of "fs:gs:[eax]", you can replace it with
> > > "fs:[eax]" to get the same output.
> > 
> > In straight line code yes. But what if a first override is hidden deep in a
> > macro you can't or don't want to modify, but you need to add an override to
> > in one special case?
> 
> Do you have a real example?

No, I don't. But I don't assume you have a real example of someone having used
something like fs:foo:[ebx] either, to support your original change. The
reporter's example, as he states, did not result in bad code being generated
(and for that case accepting the code was the intended behavior).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21874

--- Comment #10 from H.J. Lu  ---
(In reply to Jan Beulich from comment #9)
> 
> > It is more important for gas to be consistent with itself.
> 
> That's a bogus goal imo: Different assembly syntax can naturally result in

Not to me.

> apparent inconsistencies.
> 
> > In the case of "fs:gs:[eax]", you can replace it with
> > "fs:[eax]" to get the same output.
> 
> In straight line code yes. But what if a first override is hidden deep in a
> macro you can't or don't want to modify, but you need to add an override to
> in one special case?

Do you have a real example?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel

[jbeulich at novell dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21874

--- Comment #9 from Jan Beulich  ---
(In reply to H.J. Lu from comment #8)
> (In reply to Jan Beulich from comment #7)
> > (In reply to H.J. Lu from comment #6)
> > > If gas doesn't allow multiple segment registers in AT syntax, it
> > > shouldn't allow them in Intel syntax.
> > 
> > I can only keep telling you that I view maximum possible compatibility with
> > MASM more important that compatibility between the under-specified (or
> > should I say not specified at all) AT syntax. As the maintainer of the
> > Intel syntax code I would not have approved the patch in the shape you've
> > committed it. Please fix it to avoid the need to revert.
> 
> My understanding is that gas can't assemble many assembly codes which
> accept MASM.

Of course, hence me saying "maximum possible compatibility" (instead of saying
"full").

> It is more important for gas to be consistent with itself.

That's a bogus goal imo: Different assembly syntax can naturally result in
apparent inconsistencies.

> In the case of "fs:gs:[eax]", you can replace it with
> "fs:[eax]" to get the same output.

In straight line code yes. But what if a first override is hidden deep in a
macro you can't or don't want to modify, but you need to add an override to in
one special case?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21874

--- Comment #8 from H.J. Lu  ---
(In reply to Jan Beulich from comment #7)
> (In reply to H.J. Lu from comment #6)
> > If gas doesn't allow multiple segment registers in AT syntax, it
> > shouldn't allow them in Intel syntax.
> 
> I can only keep telling you that I view maximum possible compatibility with
> MASM more important that compatibility between the under-specified (or
> should I say not specified at all) AT syntax. As the maintainer of the
> Intel syntax code I would not have approved the patch in the shape you've
> committed it. Please fix it to avoid the need to revert.

My understanding is that gas can't assemble many assembly codes which
accept MASM.  It is more important for gas to be consistent with
itself. In the case of "fs:gs:[eax]", you can replace it with
"fs:[eax]" to get the same output.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21874

--- Comment #6 from H.J. Lu  ---
(In reply to Jan Beulich from comment #4)
> The adjustment done to intelok.s is was wrong here: MASM accepts that code,
> and so should gas. I certainly can agree that accepting _anything_ between
> the colons was too lax, but the change has definitely introduced a
> regression. Please fix, and for future Intel syntax changes please also
> follow the fundamental model of awaiting maintainer approval.

If gas doesn't allow multiple segment registers in AT syntax, it
shouldn't allow them in Intel syntax.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel

[jbeulich at novell dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21874

--- Comment #5 from Jan Beulich  ---
(I can't, btw, see how to change the status of the bug back from RESOLVED
FIXED, or how to re-assign it. Pretty strange a UI limitation as it seems.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel

[jbeulich at novell dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21874

Jan Beulich  changed:

   What|Removed |Added

 CC||jbeulich at novell dot com

--- Comment #4 from Jan Beulich  ---
The adjustment done to intelok.s is was wrong here: MASM accepts that code, and
so should gas. I certainly can agree that accepting _anything_ between the
colons was too lax, but the change has definitely introduced a regression.
Please fix, and for future Intel syntax changes please also follow the
fundamental model of awaiting maintainer approval.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21874

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |2.30

--- Comment #3 from H.J. Lu  ---
Fixed for 2.30.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=21874

--- Comment #2 from cvs-commit at gcc dot gnu.org  ---
The master branch has been updated by H.J. Lu :

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=4d36230d59903b92fbe2b53b31ed64a884860f0e

commit 4d36230d59903b92fbe2b53b31ed64a884860f0e
Author: H.J. Lu 
Date:   Tue Aug 1 05:53:27 2017 -0700

x86: Update segment register check in Intel syntax

https://sourceware.org/ml/binutils/2009-04/msg00223.html

introduced a new Intel syntax parser which accepts

mov eax, fs:gs:[eax]

It ignores anything between ':'s after fs and treats

mov eax, DWORD PTR fs:foobar:16
mov eax, DWORD PTR fs:foobar:barfoo:16
mov eax, DWORD PTR fs:ds:16
mov eax, DWORD PTR fs:ds:cs:16

as

mov eax, DWORD PTR fs:16

This patch updates segment register check and only allows a single ':'.

PR gas/21874
* config/tc-i386-intel.c (i386_intel_operand): Update segment
register check.
* testsuite/gas/i386/intelok.s: Replace "fs:gs:[eax]" with
"fs:[eax]".
* testsuite/gas/i386/inval-seg.s: Add tests for invalid segment
register.
* testsuite/gas/i386/x86-64-inval-seg.s: Likewise.
* testsuite/gas/i386/inval-seg.l: Updated.
* testsuite/gas/i386/x86-64-inval-seg.l: Likewise.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21874

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-01
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
Assembler just takes anything:

[hjl@gnu-tools-1 pr21874]$ cat x.s
.intel_syntax noprefix
mov eax, DWORD PTR fs:foobar:16
mov eax, DWORD PTR fs:foobar:barfoo:16
mov eax, DWORD PTR fs:ds:16
mov eax, DWORD PTR fs:ds:cs:16
[hjl@gnu-tools-1 pr21874]$ make AS=as
as --32  -o x.o x.s
[hjl@gnu-tools-1 pr21874]$ objdump -dwr x.o

x.o: file format elf32-i386


Disassembly of section .text:

 <.text>:
   0:   64 a1 10 00 00 00   mov%fs:0x10,%eax
   6:   64 a1 10 00 00 00   mov%fs:0x10,%eax
   c:   64 a1 10 00 00 00   mov%fs:0x10,%eax
  12:   64 a1 10 00 00 00   mov%fs:0x10,%eax
[hjl@gnu-tools-1 pr21874]$ 

There is even a test in gas/testsuite/gas/i386/intelok.s:

mov   eax, fs:gs:[eax]

for this syntax.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21874

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel

[ubizjak at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21874

Uros Bizjak  changed:

   What|Removed |Added

Version|unspecified |2.27

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils