[Bug gas/6957] i386 NOPs must be derived from march not mtune

2010-06-08 Thread dsd at laptop dot org

--- Additional Comments From dsd at laptop dot org  2010-06-08 21:49 ---
Created an attachment (id=4835)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4835&action=view)
testcase.s


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6957

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.

___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug gas/6957] i386 NOPs must be derived from march not mtune

2010-06-08 Thread dsd at laptop dot org

--- Additional Comments From dsd at laptop dot org  2010-06-08 21:53 ---
(In reply to comment #8)
> I agree. If it is true, assembler is broken. If you can show me
> a small testcase, I will fix it.

I can confirm the bug and I'd like to take you up on that offer, but I may have
fallen short of the *small* test case :)

I attached testcase.s which is some assembly caught from a gcc invokation inside
glibc's compile process. It's 1300 lines (sorry!) but does confirm the usage of
the nopl instruction when -mtune=i686 is passed :

$ as -Qy -o foo testcase.s
$ objdump -d foo | grep nopl
$ as -Qy -mtune=i686 -o foo testcase.s
$ objdump -d foo | grep nopl
  3d:   0f 1f 00nopl   (%eax)

Reproduced on both:
GNU assembler version 2.19.51.0.14-37.fc12 20090722
GNU assembler version 2.20.51.0.2-17.fc14 20091009

Someone more savvy with assembly code could probably cut down my test case into
something more trivial with a small amount of effort - I'm a bit out of my
comfort zone.

-- 
   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |


http://sourceware.org/bugzilla/show_bug.cgi?id=6957

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.

___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug gas/6957] i386 NOPs must be derived from march not mtune

2010-06-08 Thread dsd at laptop dot org

--- Additional Comments From dsd at laptop dot org  2010-06-08 22:04 ---
Created an attachment (id=4836)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4836&action=view)
testcase2.s

Duh. The previous testcase.s was generated using "gcc -g" so its naturally
huge. Taking off the -g results in a much smaller (95 line) test case which
shows the issue in an identical manner.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6957

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.

___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug gas/6957] i386 NOPs must be derived from march not mtune

2010-06-08 Thread dsd at laptop dot org

--- Additional Comments From dsd at laptop dot org  2010-06-08 22:07 ---
Created an attachment (id=4837)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4837&action=view)
testcase3.s

One more. By deleting (more or less) random lines from testcase2.s I came up
with a 9-line test case which produces 2 nopl instructions when assembled with
-mtune=i686.

$ as -mtune=i686 -o foo testcase3.s
$ objdump -d foo
Disassembly of section .text:

 <.text>:
   0:   55  push   %ebp
   1:   5d  pop%ebp
   2:   c3  ret
   3:   0f 1f 44 00 00  nopl   0x0(%eax,%eax,1)
   8:   c3  ret
   9:   0f 1f 80 00 00 00 00nopl   0x0(%eax)


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6957

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.

___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug gas/6957] i386 NOPs must be derived from march not mtune

2010-06-08 Thread dsd at laptop dot org

--- Additional Comments From dsd at laptop dot org  2010-06-08 22:17 ---
Oops, sorry for the test case spam. I did not see your comment.

I understand now.

"as -mtune=i686" basically works out to be "as -march=i686 -mtune=i686"

Hence generating i686-specific instructions is acceptable/expected.

My confusion stemmed from the fact that this is a minor behavioural difference
from the equivalently named parameters to gcc. (maybe this is why gcc does not
pass those parameters down to the assembler by default)

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6957

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.

___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils