+++ This bug was initially created as a clone of Bug #184446 +++ Testing the GCC patch revealed that, if you take an object file compiled with -fPIC that accesses locally-defined thread-local variables, and link that into a main executable, the linker will relax the dynamic access models incorrectly. This is true with the code we generated after the patch, but it was already true with the code we generated before, so I take it that this other error is not a blocker. Here's a testcase: bash-3.1# cat t2.c __thread int i; int f() { return i; } int main() { return 5 != f(); } bash-3.1# gcc -v Using built-in specs. Target: ppc64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --enable-secureplt --with-long-double-128 --host=ppc64-redhat-linux --build=ppc64-redhat-linux --target=ppc64-redhat-linux --with-cpu=default32 Thread model: posix gcc version 4.1.0 20060304 (Red Hat 4.1.0-2) bash-3.1# gcc -fPIC t2.c -o t2 bash-3.1# ./t2 Segmentation fault The relaxed code computes the address of the TLS variable as $r2+4096, which apparently goes beyond the end of the stack, since it's the attempt to read from it that crashes. This linker failure does not affect in any way the fix that is going into gcc-4.1.0-3, since the GCC failure was only observed in dynamic libraries, and the linker failure only affects main executables (it's the local exec access model that breaks). It might turn out that it is not a linker problem, but rather a glibc problem, if the segmentation fault is not because the relaxed code computes the wrong address for the variable, but rather that say glibc fails to map the portion of the stack reserved for the Static TLS block as readable or something like that. Very unlikely, but I thought I'd point out the possibility, just to test how long people can hold their breaths ;-)
I've just verified that glibc is not at fault, by using code in a dynamic library to determine the address of the TLS variable and then comparing the result with the address computed by the relaxed LE model: the incorrect minus the correct yield 0x8000. So I guess the linker is failing to take the TP bias into account.
Created attachment 125917 [details] Patch that fixes the bug The problem was that the relaxation code failed to discard the addend of the relocation in the call to __tls_get_addr, that in the new ABI is +32768. Since the idea is to reference the two halves of the same address in the two relaxed instructions, the correct thing to do is to copy the addend from the first to the second instruction. We already did that for LD to LE, but not in GD to LE, which sort of explains why this went unnoticed for so long. I'm building this for FC5, let's see if it makes to the release...
Created attachment 126264 [details] Backport of patch that hit upstream Upstream requested a minor cleanup, which I did before installing it there. It's not worth respinning our binutils just because of it, but you may want to enqueue an update for FC5 with it along with a better patch for bug 184446, that I'll soon attach there.
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
This bug has been in NEEDINFO for more than 30 days since feedback was first requested. As a result we are closing it. If you can reproduce this bug in the future against a maintained Fedora version please feel free to reopen it against that version. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp