Re: ppc64le: expected localentry:0 `pthread_condattr_destroy'

[Florian Weimer <fweimer at redhat dot com>]

On 07/28/2017 02:52 PM, Alan Modra wrote:
> On Fri, Jul 28, 2017 at 02:39:13PM +0200, Florian Weimer wrote:
>> On 07/28/2017 12:07 PM, Alan Modra wrote:
>>> No, you misunderstood my comment about --no-plt-localentry.  The
>>> *user* library would need to be built with that option, which isn't a
>>> good solution.
>>
>> Could you clarify how this optimization works?  Is the following
>> description accurate?
>>
>> At static link time, when processing a relocation to a function, the
>> static link editor looks at the implementation of the called function
>> (which can live in a different DSO).  If the current implementation does
>> not use the TOC register, the caller is adjusted to call an optimized
>> PLT stub which does not set the TOC.  Otherwise, a full PLT stub which
>> sets the TOC is used.  If the link edit chose to apply the optimization,
>> there is no way to go back, and future implementations of the called
>> function must never require a TOC pointer.  The dynamic linker cannot
>> recover and thus bails out with the localentry error message.
> 
> Yes, that's correct.  If the linker doesn't see a definition, or if
> the definition is weak, then the optimization does not apply.

Ugh.

This absolutely has to be disabled by default.  No one is prepared for
an ABI change because a global variable access has been added to a
function (or the compiler has decided to inline a function with a global
variable access).

In fact, I'm *extremely* reluctant to ship a distribution which as
support for this in the link editor and dynamic linker, even as an
optional feature, because developers will see this option and use it,
without realizing the full consequences (that they lose ABI forward
compatibility).

The optimization is only possible if it is source-directed, that is, the
compiler can take measures to preserve ABI in the presence of
implementation changes.  This would have to be encoded in the DSO (as a
promise “this function will never use the TOC pointer”), and static link
editor could pick up that flag and skip setting that TOC.

But we can't do that automatically just because the current
implementation has some convenient property.  Nobody knows if future
library upgrades will preserve this property.

Thanks,
Florian