This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]