Bug 411 - gcc defines __i686 macro, causing problems in sysdeps/i386/elf/setjmp.S
Summary: gcc defines __i686 macro, causing problems in sysdeps/i386/elf/setjmp.S
Status: RESOLVED FIXED
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: unspecified
: P3 minor
Target Milestone: ---
Assignee: GOTO Masanori
URL:
Keywords: glibc_2.15
: 4507 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-09-25 22:48 IST by J. Scott Berg
Modified: 2014-07-04 16:34 IST (History)
8 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Last reconfirmed:
fweimer: security-


Attachments
This lets it build for me (208 bytes, patch)
2004-10-03 02:00 IST, J. Scott Berg
Details | Diff
Patch to make it work on NPTL build (1.41 KB, patch)
2005-04-15 20:29 IST, J. Scott Berg
Details | Diff
Remove tst-cancel17.c patch from the previous (1.23 KB, patch)
2005-04-15 20:35 IST, J. Scott Berg
Details | Diff
Something was wrong with the line numbers in the previous patch, not sure how that happened... (1.23 KB, patch)
2006-02-07 20:15 IST, J. Scott Berg
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description J. Scott Berg 2004-09-25 22:48:30 IST
Since gcc-3.4.2 (and earlier versions) define the __i686 macro on a pentium3
system, things like __i686.get_pc_thunk.cx get mangled.  Thus,
sysdeps/i386/elf/setjmp.S won't compile on a pentium3 (and presumably pentium2
also).

This is 25 Sep 2004 CVS.
Comment 1 J. Scott Berg 2004-10-03 02:00:05 IST
Created attachment 219 [details]
This lets it build for me

This lets is build and everything seems to work.  I'm not sure that this is the
best of the many sysdep.h's to put it in (or even that this is the best thing
to do!).
Comment 2 J. Scott Berg 2005-04-15 20:29:15 IST
Created attachment 458 [details]
Patch to make it work on NPTL build

I upgraded to kernel 2.6.11.7 and built a nptl glibc (2.3.5 release).  Turns
out the old patch didn't fix things with NPTL.	Things seem to work with this
patch.	Note that I removed the #define from sysdep.h and instead made the
#define's more narrowly targeted.  Also, unstead of #undef'ing __i686, I
defined it to itself as suggested by a message I found on a mailing list
somewhere.

I realized that I'm getting __i686 defined because I configured my gcc-3.4.3
build with --with-cpu=pentium3 --with-arch=pentium3 --with-tune=pentium3.
Comment 3 J. Scott Berg 2005-04-15 20:35:45 IST
Created attachment 459 [details]
Remove tst-cancel17.c patch from the previous

Not paying attention, I left a workaround for the tst-cancel17 problem in that
patch.	New version has it removed.
Comment 4 Ulrich Drepper 2005-10-16 00:41:20 IST
We don't pass -march=i686 or equivalent to gcc when used on assembler files. 
Unless you do something wrong (like adding the -march parameter to CC or so)
there is no problem.
Comment 5 Ranjit Mathew 2005-10-16 02:05:24 IST
(In reply to comment #4)
> We don't pass -march=i686 or equivalent to gcc when used on assembler files. 
> Unless you do something wrong (like adding the -march parameter to CC or so)
> there is no problem.

Well, the "-march" bit gets added automatically if the compiler was
built with "--with-arch=pentium3". If I'm building a GCC for use on
only my machine, I would build it like this. The real questions are:

1. Does glibc *really* have to use stuff named "__i686", etc.?

2. What good does GCC achieve by predefining "__i686" when "-march=i686"?

I know you guys are not particularly interested in build failure
reports for glibc, but this particular one seems like something
that can easily be resolved between glibc and GCC.
Comment 6 J. Scott Berg 2006-02-07 20:15:34 IST
Created attachment 859 [details]
Something was wrong with the line numbers in the previous patch, not sure how that happened...
Comment 7 Petr.Salinger 2006-02-08 09:37:56 IST
> We don't pass -march=i686 or equivalent to gcc when used on assembler files. 
> Unless you do something wrong (like adding the -march parameter to CC or so)
> there is no problem.

Even if -march is not passed, some predefined macros are used, depending on
compiler target.

Try something like:
touch a.S
gcc -dD a.S -E

Would be possible to use name i.e.
__i686_get_pc_thunk.reg instead of  __i686.get_pc_thunk.reg ?
Comment 8 Jakub Jelinek 2006-02-08 09:42:34 IST
No, because __i686.get_pc_thunk.* is what GCC uses internally.  Calling it
differently means it can't be merged any longer with GCC created pads.
Comment 9 Petr.Salinger 2006-02-08 11:14:29 IST
> No, because __i686.get_pc_thunk.* is what GCC uses internally. 

And what about using patch based on one proposed in
http://sources.redhat.com/ml/libc-alpha/2002-10/msg00157.html

Now it should go into sysdeps/i386/sysdep.h 

Comment 10 Ulrich Drepper 2006-04-21 18:25:42 IST
"It hurts when I do this."  Then don't.  There is no need for a change.
Comment 11 David S. Miller 2010-02-24 13:38:34 IST
Ulrich, it's the default on some distributions, and now even Fedora 12 falls
into this category.

The compiler people or whoever decided to put that __i686 thing into
the CPP namespace made a mistake.  Alternatively a different name for
the getpc thunks could have been chosen.

Either way we're stuck with it and have to address it somehow.  Wishing it
didn't happen won't fix the build failures every single person who tries
to build glibc (with default settings) on Fedora 12 is going to see now.
Comment 12 Juergen Daubert 2010-04-15 08:20:07 IST
The whole issue became a new quality, because gcc 4.5.0 always set
unconditionally -march=pentiumpro if gcc was build for i686.

Please see my rejected bug report for gcc, 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43750
Comment 13 Burt Silverman 2012-01-19 02:13:32 IST
(In reply to comment #11)
> Ulrich, it's the default on some distributions, and now even Fedora 12 falls
> into this category.
> 
> The compiler people or whoever decided to put that __i686 thing into
> the CPP namespace made a mistake.  Alternatively a different name for
> the getpc thunks could have been chosen.
> 
> Either way we're stuck with it and have to address it somehow.  Wishing it
> didn't happen won't fix the build failures every single person who tries
> to build glibc (with default settings) on Fedora 12 is going to see now.
> 

I have confirmed that __i686 does not belong in the CPP namespace. I did this by carefully searching the "Using the GNU Compiler Collection" document v4.6.2 for both "macro" and "__". The onus is on the compiler folks to either re-document the compiler, or to remove __i686.

Having said that, I found that I could build glibc by adding "-U__i686" to ASFLAGS.o and ASFLAGS.os in sysdeps/i386/i686/Makefile. However, I was not successful doing "make check."
Comment 14 Marek Polacek 2012-01-19 06:32:19 IST
The GCC now uses the "__x86.get_pc_thunk" prefix.
Comment 15 Burt Silverman 2012-01-21 17:28:06 IST
(In reply to comment #14)
> The GCC now uses the "__x86.get_pc_thunk" prefix.

Thanks, Marek. So if I understand, the glibc source should be changed accordingly, __i686.get_pc_thunk -> __x86.get_pc_thunk. That will remove the conflict. Anybody feel free to contact me if I can be of any assistance.
Comment 16 Joseph Myers 2012-02-08 01:47:47 IST
This is now fixed for 2.16.
Comment 17 Joseph Myers 2012-02-18 00:16:39 IST
*** Bug 4507 has been marked as a duplicate of this bug. ***
Comment 18 Carlos O'Donell 2012-04-22 19:35:22 IST
I've checked in an alternate fix for this on the 2.15 branch.
Comment 19 Jackie Rosen 2014-02-16 19:22:47 IST Comment hidden (spam)