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

[H.J. Lu]

On Mon, Apr 18, 2016 at 10:03 AM, Maciej W. Rozycki <macro@imgtec.com> wrote:
> 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

Sorry,  this isn't how function pointer works on x86.

> 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.
>

That is why protected visibility is such a mess.

-- 
H.J.