[Bug c/46275] -masm=intel -fPIC causes global offset table issues

[Bug c/46275] -masm=intel -fPIC causes global offset table issues

[hezekiahehud at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46275

--- Comment #1 from hezekiahehud at gmail dot com 2010-11-02 18:30:50 UTC ---
Created attachment 22232
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22232
Preprocessed source code

[Bug c/46275] New: -masm=intel -fPIC causes global offset table issues

[hezekiahehud at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46275

           Summary: -masm=intel -fPIC causes global offset table issues
           Product: gcc
           Version: 4.4.5
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: hezekiahehud@gmail.com


Created attachment 22231
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22231
Output from gcc -v -save-temps ...

The combination of -masm=intel and -fPIC when producing 32-bit causes strange
behaviour when dealing with globals.  Specifically, it looks like calculations
using the global offset table are being done incorrectly.  (I'm not sure if
this is because the EBX register was loaded with the wrong value or if the
computations using it are somehow off.)

You can reproduce the bug with a simple Hello World program.  I used the
following code and the command "gcc -m32 -fPIC -masm=intel -o hello hello.c":

#include <stdio.h>
int main()
{ puts("Hello, world!"); }

If you run the resulting 32-bit ELF, you get an output other than "Hello,
world!"  (In my case, I get a single 0x02 byte and the newline added by puts.) 
As far as my debugging has shown, it appears that an incorrect address is
computed for the "Hello, world!" global string constant.

If you compile the same code either without -fPIC or without -masm=intel, the
resulting executable works as expected.

I originally discovered the bug on a 32-bit system with a 32-bit gcc
executable, so it does not seem to be specific to running the compiler in a
64-bit environment; the 32-bit output seems to be the important part.


I have attached the compiler output from a -v -save-temps run.  I will attach
the hello.i file shortly.

[Bug target/46275] -masm=intel -fPIC causes global offset table issues

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46275

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |i686-linux-gnu
          Component|c                           |target
           Severity|major                       |normal

[Bug target/46275] -masm=intel -fPIC causes global offset table issues

[hezekiahehud at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46275

--- Comment #2 from hezekiahehud at gmail dot com 2010-11-02 18:33:19 UTC ---
Created attachment 22233
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22233
Repro on GCC 4.5.1

I've also reproduced this bug on GCC 4.5.1 in the same environment.

[Bug target/46275] -masm=intel -fPIC causes global offset table issues

[hezekiahehud at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46275

hezekiahehud at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |major

[Bug target/46275] -masm=intel -fPIC causes global offset table issues

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46275

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|major                       |normal

[Bug target/46275] -masm=intel -fPIC causes global offset table issues

[hezekiahehud at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46275

--- Comment #3 from hezekiahehud at gmail dot com 2010-11-02 18:53:55 UTC ---
Apologies for the severity change, Andrew.  Shortly after filing the bug, I saw
the severity was "normal" and thought perhaps the system had glitched or I had
forgotten to set that field of the form.  I didn't see the email showing you
had altered the severity until after I had bumped it to "major" again.

That being said, company I work for is attempting to complete a 32-bit Linux
port of our primary product wholly using GCC (we are currently using a GCC and
Intel compiler mix), and -masm=intel is an unavoidable requirement for our
code.  This bug is a serious problem for us.  I defer to your judgement on the
relevant severity of bugs, but please realise that this has considerably more
impact than the simple "hello, world" example I gave.

[Bug target/46275] -masm=intel -fPIC causes global offset table issues

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46275

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> 2010-11-02 18:59:00 UTC ---
-masm=intel is really only needed if you are going to do some post processing
of the assembly code or want to read the assembly code in the Intel (non AT&T)
format.  It should not change the code generation or the ABI.  Also it should
be noted that the Intel compiler under GNU/Linux outputs assembly code in the
AT&T format by default.  Also note the generated object files will be the same. 

>From what you mentioned in comment #3, I don't see a reason to use -masm=intel.
 Do you post process the assembly code?

[Bug target/46275] -masm=intel -fPIC causes global offset table issues

[hezekiahehud at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46275

--- Comment #5 from hezekiahehud at gmail dot com 2010-11-02 19:08:32 UTC ---
The source code in question is for an anti-virus product, originally targeting
Windows.  It contains a great deal of inline assembly code, all of which is
written in Intel syntax.  The reason for the existing GCC + Intel compiler mix
is because the Intel compiler happily accepts the same Intel-style assembly
syntax and the same syntax for block-scoped assembly as MSVC.  However, we want
to move away from the Intel compiler.

So, we are working on a port to pure GCC and have worked our way around the
block-syntax and other MSVC-and-Intel-compiler-specific-syntax related issues,
but we cannot justify maintaining two copies of the same large set of inline
assembly code, one in AT&T and one in Intel syntax.  Hence, the requirement for
-masm=intel.

I realize that -masm=intel might not be a widely used option, but does that
really matter?  Ultimately, the compiler is producing bad output that will kill
any 32-bit program that uses globals compiled with -masm=intel -fPIC.  I once
again admit my ignorance of the relative severity of GCC bugs, but that seems
pretty bad to me.


(In reply to comment #4)
> -masm=intel is really only needed if you are going to do some post processing
> of the assembly code or want to read the assembly code in the Intel (non AT&T)
> format.  It should not change the code generation or the ABI.  Also it should
> be noted that the Intel compiler under GNU/Linux outputs assembly code in the
> AT&T format by default.  Also note the generated object files will be the same. 
> 
> From what you mentioned in comment #3, I don't see a reason to use -masm=intel.
>  Do you post process the assembly code?

[Bug target/46275] -masm=intel -fPIC causes global offset table issues

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46275

Uros Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl.tools at gmail dot com

--- Comment #6 from Uros Bizjak <ubizjak at gmail dot com> 2010-11-02 21:07:24 UTC ---
This looks like assembler problem to me. Adding CC.

[Bug target/46275] -masm=intel -fPIC causes global offset table issues

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46275

--- Comment #7 from Uros Bizjak <ubizjak at gmail dot com> 2010-11-03 08:47:48 UTC ---
For some reason, the addend in R_386_GOTPC reloc is missing when compiled with
-masm=intel. The objdump difference between -masm=att [hello.o] that works and
-masm=intel [hello_.o] that fails is:

@@ -1,5 +1,5 @@

-hello.o:     file format elf32-i386
+hello_.o:     file format elf32-i386


 Disassembly of section .text:
@@ -12,7 +12,7 @@
    7:    83 ec 1c                 sub    $0x1c,%esp
    a:    e8 fc ff ff ff           call   b <main+0xb>
             b: R_386_PC32    __i686.get_pc_thunk.bx
-   f:    81 c3 02 00 00 00        add    $0x2,%ebx
+   f:    81 c3 00 00 00 00        add    $0x0,%ebx
             11: R_386_GOTPC    _GLOBAL_OFFSET_TABLE_
   15:    8d 83 00 00 00 00        lea    0x0(%ebx),%eax
             17: R_386_GOTOFF    .rodata

[Bug target/46275] -masm=intel -fPIC causes global offset table issues

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46275

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                URL|                            |http://sourceware.org/bugzi
                   |                            |lla/show_bug.cgi?id=12186
         Resolution|                            |INVALID

--- Comment #8 from H.J. Lu <hjl.tools at gmail dot com> 2010-11-03 14:03:34 UTC ---
It is an assembler bug. Intel syntax isn't well tested. I will
try to fix it:

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

But you may run into more Intel syntax bugs.

[Bug target/46275] -masm=intel -fPIC causes global offset table issues

[hezekiahehud at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46275

--- Comment #9 from hezekiahehud at gmail dot com 2010-11-03 14:12:57 UTC ---
Thank you. :-)

(In reply to comment #8)
> It is an assembler bug. Intel syntax isn't well tested. I will
> try to fix it:
> 
> http://sourceware.org/bugzilla/show_bug.cgi?id=12186
> 
> But you may run into more Intel syntax bugs.