[Bug dynamic-link/21847] ppc64le: expected localentry:0 `pthread_…' ld.so error prevents allocation startup

["amodra at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

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

--- Comment #4 from Alan Modra <amodra at gmail dot com> ---
The problem is this:

amodra@pike:~/build/glibc$ readelf -s ./libc.so.6 | grep
pthread_condattr_destroy
  1344: 000000000012e420   108 FUNC    GLOBAL DEFAULT [<localentry>: 8]    10
pthread_condattr_destroy@@GLIBC_2.17
  5940: 000000000012e420   108 FUNC    GLOBAL DEFAULT [<localentry>: 8]    10
pthread_condattr_destroy
amodra@pike:~/build/glibc$ readelf -s ./nptl/libpthread.so.0 | grep
pthread_condattr_destroy
   299: 0000000000011f70    20 FUNC    GLOBAL DEFAULT   11
pthread_condattr_destroy@@GLIBC_2.17
   181: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS
pthread_condattr_destroy.
   694: 0000000000011f70    20 FUNC    GLOBAL DEFAULT   11
pthread_condattr_destroy

libpthread.so.0 has a stub implementation of pthread_condattr_destroy which
consists of just
  ld r3,0
  blr

while libc.so.6 has the full implementation.  Users link against libpthread.so
which means ld sees the stub symbol first before finding the real
implementation in libc.so.  By the usual rules of duplicate symbol resolution
involving shared libraries, ld must take the first symbol as the definition. 
The stub symbol of course doesn't need a toc pointer so the optimised
localentry:0 call is used.  At runtime, ld.so apparently resolves
pthread_condattr_destroy to the libc version, which isn't localentry:0.

I'm not familiar with the reasons for glibc having two conflicting
implementations for pthread functions, but I believe the correct fix is to make
the libpthread.so stub symbols weak.

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