[Bug target/32219] optimizer causes wrong code in pic/hidden/weak symbol checking.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32219 Mikael Pettersson changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #14 from Mikael Pettersson 2012-09-01 15:17:28 UTC --- (In reply to comment #13) > This was (accidentally) fixed on for at least 4.7 ff but without adding a > testcase like the attached. Are you sure it's been fixed? The test case segfaults for me on x86_64-linux when compiled by 4.8-20120826, 4.7-20120825, or 4.6-20120810, with -O1 -m32 and -fPIC or -fPIE. Without -m32 it doesn't segfault.
[Bug target/32219] optimizer causes wrong code in pic/hidden/weak symbol checking.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32219 --- Comment #13 from Bernhard Reutner-Fischer 2012-06-28 22:49:52 UTC --- Created attachment 27716 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27716 testcase This was (accidentally) fixed on for at least 4.7 ff but without adding a testcase like the attached.
[Bug target/32219] optimizer causes wrong code in pic/hidden/weak symbol checking.
--- Comment #12 from ncopa at alpinelinux dot org 2010-06-30 11:52 --- whats the status on this bug? It still happens on gcc-4.4.4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32219
[Bug target/32219] optimizer causes wrong code in pic/hidden/weak symbol checking.
--- Comment #11 from aldot at gcc dot gnu dot org 2010-03-16 13:35 --- (In reply to comment #10) > Well, simply re-ordering the visibility and the weak check in > varasm.c:default_binds_local_p_1 should do the trick. > It does. http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00665.html -- aldot at gcc dot gnu dot org changed: What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32219
[Bug target/32219] optimizer causes wrong code in pic/hidden/weak symbol checking.
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-03-09 12:39 --- Well, simply re-ordering the visibility and the weak check in varasm.c:default_binds_local_p_1 should do the trick. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32219
[Bug target/32219] optimizer causes wrong code in pic/hidden/weak symbol checking.
--- Comment #9 from aldot at gcc dot gnu dot org 2010-03-08 19:28 --- (In reply to comment #8) > What's the status of this bug ? we currently still end up with call 0 on e.g. i386 > The same things can happen in libraries with fpic yes. Thing is that we could theoretically work around it by explicitly looking at the addr ¹) but that's just plain disgusting imho. And the hardened guys will not like the idea to drop DOPIC (i.e. build members of .a without PIC). So.. What's the status of that bug? Current binutils-2.20 and somewhat current gcc basically generate "wrong" code, or at least code that behaves in an unpleasant way causing grief.. ¹) https://bugs.uClibc.org/1033 thanks and cheers, -- aldot at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-03-08 19:28:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32219
[Bug target/32219] optimizer causes wrong code in pic/hidden/weak symbol checking.
--- Comment #8 from castet dot matthieu at free dot fr 2009-12-29 23:20 --- What's the status of this bug ? The same things can happen in libraries with fpic -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32219
[Bug target/32219] optimizer causes wrong code in pic/hidden/weak symbol checking.
--- Comment #7 from hjl dot tools at gmail dot com 2008-02-25 22:16 --- It is a compiler bug after all. From: http://groups.google.com/group/generic-abi/browse_thread/thread/4364eb484397ebe0 A hidden symbol must be defined in the same component, *if it is defined at all*. That last part is the key to the issue. In the case of a WEAK HIDDEN UNDEF symbol, it is possible for the symbol to remain undefined (or, looked at another way, it is possible for the symbol to be defined at link time as an absolute symbol with value 0). I agree with Daniel; the compiler should be aware of this possibility and generate code that will not require a dynamic relocation for this case. For a weak and hidden symbol, it is bound local only if PIC is false or it is used for branch. Otherwise, it should be treated with default visibility. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | Version|4.2.1 |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32219
[Bug target/32219] optimizer causes wrong code in pic/hidden/weak symbol checking.
--- Comment #6 from hjl dot tools at gmail dot com 2008-02-23 23:12 --- Weak and hidden aren't really compatible. Linker should enforce it. I opened a linker bug: http://sourceware.org/bugzilla/show_bug.cgi?id=5789 As for gcc, I think it is OK since it is a user error and linker should issue an error. Besides, gcc doesn't know if the .o file will be used for PIE/shared library or normal executable. The runtime error only happens with PIE/shared library, not normal executable. -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://sourceware.org/bugzil ||la/show_bug.cgi?id=5789 Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32219
[Bug target/32219] optimizer causes wrong code in pic/hidden/weak symbol checking.
--- Comment #5 from pluto at agmk dot net 2008-02-23 21:09 --- (In reply to comment #3) > (In reply to comment #2) > > > Also you should be using -PIE when linking. > > hmm, it doesn't work with int main(); > > $ gcc -s main.c -fpie -Wl,-pie > /usr/bin/ld: /usr/lib64/crt1.o: relocation R_X86_64_32S against > `__libc_csu_fini' can not be used when making a shared object; > recompile with -fPIC > /usr/lib64/crt1.o: could not read symbols: Bad value > collect2: ld returned 1 exit status > > huh, glibc bug, linker bug? with gcc-4.2.3 and binutils-2.18.50.0.4 it links fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32219
[Bug target/32219] optimizer causes wrong code in pic/hidden/weak symbol checking.
--- Comment #4 from pluto at agmk dot net 2007-06-05 14:13 --- (In reply to comment #2) > f always will bind local ... so, should gcc reject weak attribute in this (hidden visibility) case? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32219
[Bug target/32219] optimizer causes wrong code in pic/hidden/weak symbol checking.
--- Comment #3 from pluto at agmk dot net 2007-06-05 14:10 --- (In reply to comment #2) > Also you should be using -PIE when linking. hmm, it doesn't work with int main(); $ gcc -s main.c -fpie -Wl,-pie /usr/bin/ld: /usr/lib64/crt1.o: relocation R_X86_64_32S against `__libc_csu_fini' can not be used when making a shared object; recompile with -fPIC /usr/lib64/crt1.o: could not read symbols: Bad value collect2: ld returned 1 exit status huh, glibc bug, linker bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32219
[Bug target/32219] optimizer causes wrong code in pic/hidden/weak symbol checking.
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-05 13:30 --- f always will bind local ... Also you should be using -PIE when linking. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32219
[Bug target/32219] optimizer causes wrong code in pic/hidden/weak symbol checking.
--- Comment #1 from pluto at agmk dot net 2007-06-05 12:53 --- btw, imho the weak+hidden is not a valid combination. such symbol can't be resolved in runtime because it doesn't exist in elf rel.plt/rel.dyn tables. it can be resolved only during linking several objects into one piece (e.g. exec/shlib), but in such case the weak+hidden behaves like plain hidden. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32219
