This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug dynamic-link/21847] ppc64le: expected localentry:0 `pthread_…' ld.so error prevents allocation startup
- From: "fweimer at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Fri, 28 Jul 2017 10:11:07 +0000
- Subject: [Bug dynamic-link/21847] ppc64le: expected localentry:0 `pthread_…' ld.so error prevents allocation startup
- Auto-submitted: auto-generated
- References: <bug-21847-131@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=21847
--- Comment #5 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Alan Modra from comment #4)
> 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
But this is the full implementation. The stub implementation is in libc.so.6.
I agree that it is bizarre that the stub implementation does more work than the
real implementation, but that's just an artifact of pthread_condattr_destroy.
The problem also happens with pthread_mutex_destroy, where there is actually
some code in libpthread.
> 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.
How does this optimization work? Does the link editor detect that the
implementation in libpthread does not require the TOC pointer and then
activates the optimization? What happens if we change the implementation
later, so that it needs a TOC pointer?
I still think this optimization has a general issue with symbol interposition.
> 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.
That seems wrong because the libpthread implementation is the real (full)
implementation.
--
You are receiving this mail because:
You are on the CC list for the bug.