Bug 199897

Summary: crtfastmath.o uses i686-only .align expansions
Product: [Fedora] Fedora Reporter: Miloslav Trmač <mitr>
Component: gccAssignee: Jakub Jelinek <jakub>
Status: CLOSED DUPLICATE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-08-03 09:36:06 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Miloslav Trmač 2006-07-24 06:17:16 UTC 
Disclaimer: I have very little experience with the internals of the GNU
toolchain, and this maybe manifests only in qemu; feel free to close NOTABUG.

Version-Release number of selected component (if applicable):
gcc-4.1.1-9

To reproduce: (/sbin/sysctl) crashes with SIGILL on rawhide in qemu.

binutils have recently started using new byte sequences for .align, at least if
the target architecture is i686.  For some reason the i686-only sequence appears
in crtfastmath.o:
  83:   0f ae 95 e4 fd ff ff    ldmxcsr 0xfffffde4(%ebp)
  8a:   66                      data16
  8b:   0f 1f                   (bad)
  8d:   44                      inc    %esp
  8e:   00 00                   add    %al,(%eax)
This byte sequence is currently executed only if SSE is supported, so this
might cause crashes only in qemu - this is the first time I've heard about
them, I don't know.

Unfortunately I can't find a reason why the i686-only sequence is used;
AFAICS (when rebuilding gcc on fc5) crtfastmath.c is compiled with
-march=i386 -mtune=generic.  Is gas perhaps switching to i686 automatically
after encountering an i686-only instruction?
Comment 1 Jakub Jelinek 2006-08-03 09:36:06 UTC 
Should be fixed in gcc-4.1.1-14, which has been rebuilt with a fixed assembler.
Anyway, guess qemu should support the nopl insns, if it pretends to be a '6' or
'f' family CPU.

*** This bug has been marked as a duplicate of 200330 ***