Preventing preemption of 'protected' symbols in GNU ld 2.26

[Alan Modra]

On Mon, Mar 28, 2016 at 03:38:01PM -0700, Cary Coutant wrote:
> >>> Did you look at what the costs were in startup time and dirty pages by using
> >>> copy relocations? What do you do if the size of the definition changes in a
> >>> new version of the library?
> >>
> >> There wouldn't be a measurable cost in dirty pages; the copied objects
> >> are simply allocated in bss in the executable.
> >
> > Wouldn't references to the symbol from within the .so need to be relocated to reference the now-canonical copy in the executable?
> 
> No, references from within the .so would have always used the GOT.
> Non-protected global symbols in a shared library are still
> pre-emptible, so they are always indirect, and there's always a
> dynamic relocation for the GOT entry. Whether the prevailing
> definition winds up in the executable or the shared library, the
> dynamic loader still has to bind the symbol and apply the relocation.

HJ's changes to protected visibility meant compiler changes so that
protected visibility in shared libraries is no longer seen as local.
So yes, protected visibility symbols in shared libraries now go
through the GOT.  Prior to his changes, they were optimized to a
pc-relative access.  Joe is correct in pointing out that shared
libraries needed a change.  Bad luck if you're using an older
compiler.  Also bad luck if you want to use protected visibility to
optimize your shared library.

HJ also made glibc ld.so changes to ensure the semantics of protected
visibility symbols remain unchanged when multiple shared libraries
define the same protected visibility symbol.

Apparently most people in the gcc and glibc communities saw these
toolchain modifications as fiendishly clever.

-- 
Alan Modra
Australia Development Lab, IBM