Bug 184590

Summary: TLS GD code relaxed LE crashes at run time
Product: [Fedora] Fedora Reporter: Alexandre Oliva <aoliva>
Component: binutilsAssignee: Jakub Jelinek <jakub>
Status: CLOSED INSUFFICIENT_DATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: aoliva, dcantrell, drepper, jan.kratochvil, rth, triage
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: powerpc   
OS: Linux   
Whiteboard: bzcl34nup
Fixed In Version: binutils-2.16.91.0.6-4 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-05-07 00:26:18 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 184446    
Bug Blocks:    
Attachments:
Description Flags
Patch that fixes the bug
none
Backport of patch that hit upstream none

Description Alexandre Oliva 2006-03-10 01:20:21 UTC 
+++ 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 ;-)
Comment 1 Alexandre Oliva 2006-03-10 01:32:41 UTC 
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.
Comment 2 Alexandre Oliva 2006-03-10 02:49:32 UTC 
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...
Comment 3 Alexandre Oliva 2006-03-17 06:48:22 UTC 
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.
Comment 4 Red Hat Bugzilla 2007-02-05 18:57:52 UTC 
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.
Comment 5 Bug Zapper 2008-04-03 17:06:57 UTC 
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.
Comment 6 Bug Zapper 2008-05-07 00:26:15 UTC 
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