public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/46275] -masm=intel -fPIC causes global offset table issues
2010-11-02 18:30 [Bug c/46275] New: -masm=intel -fPIC causes global offset table issues hezekiahehud at gmail dot com
@ 2010-11-02 18:30 ` hezekiahehud at gmail dot com
2010-11-02 18:31 ` [Bug target/46275] " pinskia at gcc dot gnu.org
` (10 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: hezekiahehud at gmail dot com @ 2010-11-02 18:30 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c/46275] New: -masm=intel -fPIC causes global offset table issues
@ 2010-11-02 18:30 hezekiahehud at gmail dot com
2010-11-02 18:30 ` [Bug c/46275] " hezekiahehud at gmail dot com
` (11 more replies)
0 siblings, 12 replies; 13+ messages in thread
From: hezekiahehud at gmail dot com @ 2010-11-02 18:30 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/46275] -masm=intel -fPIC causes global offset table issues
2010-11-02 18:30 [Bug c/46275] New: -masm=intel -fPIC causes global offset table issues hezekiahehud at gmail dot com
2010-11-02 18:30 ` [Bug c/46275] " hezekiahehud at gmail dot com
@ 2010-11-02 18:31 ` pinskia at gcc dot gnu.org
2010-11-02 18:33 ` hezekiahehud at gmail dot com
` (9 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: pinskia at gcc dot gnu.org @ 2010-11-02 18:31 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/46275] -masm=intel -fPIC causes global offset table issues
2010-11-02 18:30 [Bug c/46275] New: -masm=intel -fPIC causes global offset table issues hezekiahehud at gmail dot com
2010-11-02 18:30 ` [Bug c/46275] " hezekiahehud at gmail dot com
2010-11-02 18:31 ` [Bug target/46275] " pinskia at gcc dot gnu.org
@ 2010-11-02 18:33 ` hezekiahehud at gmail dot com
2010-11-02 18:35 ` hezekiahehud at gmail dot com
` (8 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: hezekiahehud at gmail dot com @ 2010-11-02 18:33 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/46275] -masm=intel -fPIC causes global offset table issues
2010-11-02 18:30 [Bug c/46275] New: -masm=intel -fPIC causes global offset table issues hezekiahehud at gmail dot com
` (2 preceding siblings ...)
2010-11-02 18:33 ` hezekiahehud at gmail dot com
@ 2010-11-02 18:35 ` hezekiahehud at gmail dot com
2010-11-02 18:40 ` pinskia at gcc dot gnu.org
` (7 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: hezekiahehud at gmail dot com @ 2010-11-02 18:35 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46275
hezekiahehud at gmail dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |major
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/46275] -masm=intel -fPIC causes global offset table issues
2010-11-02 18:30 [Bug c/46275] New: -masm=intel -fPIC causes global offset table issues hezekiahehud at gmail dot com
` (3 preceding siblings ...)
2010-11-02 18:35 ` hezekiahehud at gmail dot com
@ 2010-11-02 18:40 ` pinskia at gcc dot gnu.org
2010-11-02 18:54 ` hezekiahehud at gmail dot com
` (6 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: pinskia at gcc dot gnu.org @ 2010-11-02 18:40 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/46275] -masm=intel -fPIC causes global offset table issues
2010-11-02 18:30 [Bug c/46275] New: -masm=intel -fPIC causes global offset table issues hezekiahehud at gmail dot com
` (4 preceding siblings ...)
2010-11-02 18:40 ` pinskia at gcc dot gnu.org
@ 2010-11-02 18:54 ` hezekiahehud at gmail dot com
2010-11-02 18:59 ` pinskia at gcc dot gnu.org
` (5 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: hezekiahehud at gmail dot com @ 2010-11-02 18:54 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/46275] -masm=intel -fPIC causes global offset table issues
2010-11-02 18:30 [Bug c/46275] New: -masm=intel -fPIC causes global offset table issues hezekiahehud at gmail dot com
` (5 preceding siblings ...)
2010-11-02 18:54 ` hezekiahehud at gmail dot com
@ 2010-11-02 18:59 ` pinskia at gcc dot gnu.org
2010-11-02 19:08 ` hezekiahehud at gmail dot com
` (4 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: pinskia at gcc dot gnu.org @ 2010-11-02 18:59 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/46275] -masm=intel -fPIC causes global offset table issues
2010-11-02 18:30 [Bug c/46275] New: -masm=intel -fPIC causes global offset table issues hezekiahehud at gmail dot com
` (6 preceding siblings ...)
2010-11-02 18:59 ` pinskia at gcc dot gnu.org
@ 2010-11-02 19:08 ` hezekiahehud at gmail dot com
2010-11-02 21:07 ` ubizjak at gmail dot com
` (3 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: hezekiahehud at gmail dot com @ 2010-11-02 19:08 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/46275] -masm=intel -fPIC causes global offset table issues
2010-11-02 18:30 [Bug c/46275] New: -masm=intel -fPIC causes global offset table issues hezekiahehud at gmail dot com
` (7 preceding siblings ...)
2010-11-02 19:08 ` hezekiahehud at gmail dot com
@ 2010-11-02 21:07 ` ubizjak at gmail dot com
2010-11-03 8:48 ` ubizjak at gmail dot com
` (2 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: ubizjak at gmail dot com @ 2010-11-02 21:07 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/46275] -masm=intel -fPIC causes global offset table issues
2010-11-02 18:30 [Bug c/46275] New: -masm=intel -fPIC causes global offset table issues hezekiahehud at gmail dot com
` (8 preceding siblings ...)
2010-11-02 21:07 ` ubizjak at gmail dot com
@ 2010-11-03 8:48 ` ubizjak at gmail dot com
2010-11-03 14:03 ` hjl.tools at gmail dot com
2010-11-03 14:13 ` hezekiahehud at gmail dot com
11 siblings, 0 replies; 13+ messages in thread
From: ubizjak at gmail dot com @ 2010-11-03 8:48 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/46275] -masm=intel -fPIC causes global offset table issues
2010-11-02 18:30 [Bug c/46275] New: -masm=intel -fPIC causes global offset table issues hezekiahehud at gmail dot com
` (9 preceding siblings ...)
2010-11-03 8:48 ` ubizjak at gmail dot com
@ 2010-11-03 14:03 ` hjl.tools at gmail dot com
2010-11-03 14:13 ` hezekiahehud at gmail dot com
11 siblings, 0 replies; 13+ messages in thread
From: hjl.tools at gmail dot com @ 2010-11-03 14:03 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/46275] -masm=intel -fPIC causes global offset table issues
2010-11-02 18:30 [Bug c/46275] New: -masm=intel -fPIC causes global offset table issues hezekiahehud at gmail dot com
` (10 preceding siblings ...)
2010-11-03 14:03 ` hjl.tools at gmail dot com
@ 2010-11-03 14:13 ` hezekiahehud at gmail dot com
11 siblings, 0 replies; 13+ messages in thread
From: hezekiahehud at gmail dot com @ 2010-11-03 14:13 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2010-11-03 14:13 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-11-02 18:30 [Bug c/46275] New: -masm=intel -fPIC causes global offset table issues hezekiahehud at gmail dot com
2010-11-02 18:30 ` [Bug c/46275] " hezekiahehud at gmail dot com
2010-11-02 18:31 ` [Bug target/46275] " pinskia at gcc dot gnu.org
2010-11-02 18:33 ` hezekiahehud at gmail dot com
2010-11-02 18:35 ` hezekiahehud at gmail dot com
2010-11-02 18:40 ` pinskia at gcc dot gnu.org
2010-11-02 18:54 ` hezekiahehud at gmail dot com
2010-11-02 18:59 ` pinskia at gcc dot gnu.org
2010-11-02 19:08 ` hezekiahehud at gmail dot com
2010-11-02 21:07 ` ubizjak at gmail dot com
2010-11-03 8:48 ` ubizjak at gmail dot com
2010-11-03 14:03 ` hjl.tools at gmail dot com
2010-11-03 14:13 ` hezekiahehud at gmail dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).