[Bug dynamic-link/20521] New: Weak references to thread-locals are unusable on x86-64

["srk31 at srcf dot ucam.org" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=20521

            Bug ID: 20521
           Summary: Weak references to thread-locals are unusable on
                    x86-64
           Product: glibc
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: dynamic-link
          Assignee: unassigned at sourceware dot org
          Reporter: srk31 at srcf dot ucam.org
  Target Milestone: ---

Usually with weak symbol references, we can test for the presence of an
optional definition by comparing its address against null/zero. On x86-64, this
seems not to work for thread-locals... consider the following C program.

#include <stdio.h>

extern __thread int thing __attribute__((weak));

int main(void)
{
   printf("Do we have the thing? %s (%p)\n", &thing ? "yes" : "no", &thing);
   return 0;
}

When I build and run this program on x86-64, "thing" always gets a non-zero
address, even when no "thing" is linked in.

From my reading of glibc's ld.so, what happens is that the absent weak
definition is given an offset of zero from the TLS base address. When these are
added, it gives a non-null pointer (aliasing some other TLS object, I guess).

This is probably an ABI spec bug, not a glibc or ld bug per se. If I recall,
the ARM ABI specifies that unresolved weak TLS symbols are assigned an offset
equal to the *negation* of the TLS base, so when they are added, the result is
indeed zero. The x86-64 ABI has no such provision. Unless I'm missing
something, that makes weak thread-locals impossible to use.

Anyway, posting here for comments....

-- 
You are receiving this mail because:
You are on the CC list for the bug.