Red Hat Bugzilla – Bug 175442
visibility handling causes bad jump generation
Last modified: 2007-11-30 17:11:18 EST
Description of problem: I was looking into why firefox/thunderbird/mozilla have so many text relocations. Both on FC4 and devel. It turns out the compiler is buggy when it comes to implicitly generated calls and visibility. With gcc 4.0.2-3 the problem is even worse since also ordinary calls are affected. Version-Release number of selected component (if applicable): gcc-4.0.2-3 gcc-4.1.0-0.6 How reproducible: always Steps to Reproduce: I'll attach two test cases: 1.compile with gcc -c -fpic -O2 -fno-builtin <FILE>.c 2.readelf -r <FILE>.o | fgrep memcpy 3. Actual results: 0x000000XX 386_PC32 0000000000 memcpy Expected results: 0x000000XX 386_PLT32 0000000000 memcpy Additional info:
Created attachment 122100 [details] This test fails only with gcc 4.0.2.
Created attachment 122101 [details] Test case with implicit call generation This test fails with gcc 4.0.2 and gcc 4.1.0.
Argh, I meant use gcc -c -fpic -Os -fno-builtin <FILE>.c Note: -Os, not -O2.
This is upstream PR20297 I'd say, but there are many other unresolved GCC problems with visibility (mainly in C++ land). The most important ones are I think PR20297, PR19664, PR21581 and PR21764 but I've added external references to other relevant upstream bugreports. I think this is something that should be resolved soon, for FC5/GCC 4.2 and can be backported to selected compilers, because without resolving at least the more important bugs applications that use #pragma GCC visibility or -fvisibility=... (there are many now), if they work, work often by pure luck. For PR20297, Roger's http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00321.html contains some good comments about it.
Agreed that this is a major problem. However, want weak versioning patches finished first.... which also impact linkage for FC5. Then I'll start paying more attention to the vis stuff.
Would be nice to get this for FC5 for the big apps that use it (firefox, thunderbird, mozilla, etc). Adding to FC5Target
Created attachment 126379 [details] testcase with implicit call generation and no #includes Since I just spent a good bit of time simplifying this before drepper pointed me to this bug, I may as well attach it; it has the advantage of not having any #includes, since none are needed to see the bug in the implicit call generation case.
Created attachment 126380 [details] testcase with implicit call generation and no #includes
Can we just make this a tracker bug for all the gcc bugs WRT visibility?
I think so.
There were a bunch of commits for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20297 recently. Those may have fixed the text relocations in Mozilla described in comment 0, although I haven't tested.
Sure, and not just PR20297. But some of the changes now expose latent bugs much more frequently. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187399 http://gcc.gnu.org/PR27000 http://gcc.gnu.org/PR26612 So, I'm going to revert PR c++/21764, c++/19238, c++/21581 fixes from rawhide for the time being, until PR27000 and PR26612 get resolved.
It looks like the fix for this shipped in the FC5 update to gcc 4.1.1.
I think we can close this now, to my knowledge all known visibility issues but #198967 have been already resolved on redhat/gcc-4_1-branch.