Re: ppc64le: expected localentry:0 `pthread_condattr_destroy'

[Florian Weimer <fweimer at redhat dot com>]

On 07/29/2017 06:44 AM, Alan Modra wrote:
> +@cindex PowerPC64 ELFv2 PLT localentry optimization
> +@kindex --plt-localentry
> +@kindex --no-plt-localentry
> +@item --plt-localentry
> +@itemx --no-localentry
> +ELFv2 functions with localentry:0 are those with a single entry point,
> +ie. global entry == local entry, and that have no requirement on r2
> +(the TOC/GOT pointer) or r12, and guarantee r2 is unchanged on return.
> +Such an external function can be called via the PLT without saving r2
> +or restoring it on return, avoiding a common load-hit-store for small
> +functions.   The optimization is attractive, with up to 40% reduction
> +in execution time for a small function, but can result in symbol
> +interposition failures.  Use with care.  @option{--no-plt-localentry}
> +is the default.

I think this is still very misleading.

The documentation should make the following things clear:

* If objects are linked with --plt-localentry, it is likely that at run
time, the exact same version of the object will be required by the
dynamic linker.  Even supposedly ABI-compatible library updates may not
work.

* Mere recompilation of shared object dependencies can prevent loading
of objects linked with --plt-localentry even if the sources are
unchanged.  Compiler flag changes (such as optimization levels) and
compiler version changes affect compatibility.

* There is no promise  that applications which link to the core GNU
toolchain libraries (libgcc_s, glibc, libstdc++) will continue to load
after any change to these libraries, even though these libraries
generally maintain ABI backward compatibility.

The point about symbol interposition is valid, but it is really not the
core issue here.

The source code comment should be adjusted in a similar way.

Thanks,
Florian