Preventing preemption of 'protected' symbols in GNU ld 2.26 [aka should we revert the fix for 65248]

[Maciej W. Rozycki]

On Mon, 18 Apr 2016, H.J. Lu wrote:

> > Any testcase the takes the address of a protected visibility variable
> > defined in a shared library now can get the wrong answer, since you
> > can argue that any address outside the shared library is wrong
> > according to the gABI.
> 
> What value should you get when taking an address of a function
> with protected visibility inside the shared library?  Should it be
> pointed to the function body or its PLT entry in the executable
> which calls the function?

 I think it has to be an address within the shared library itself, that is 
-- depending on the particular psABI -- either the function body or its 
corresponding PLT entry in the DSO, but not in the main executable.  The 
reason is DSO code (also handcoded assembly) may reasonably expect to be 
able to load the address with a PC-relative load-address type instruction 
(ADDIUPC, LEA, MOVAB, etc.) and the target may not even have suitable 
dynamic relocations available to apply any load-time fixup if the symbol 
referred turns up outside of the DSO.  The instruction used may have a 
PC-relative range limit too.

  Maciej