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

["Maciej W. Rozycki" <macro@imgtec.com>]

On Mon, 18 Apr 2016, Michael Matz wrote:

> E.g. one limitation might very well be that function pointer comparison 
> for protected functions doesn't work (gives different outcomes if the 
> pointer is built from inside the exe or from a shared lib).  (No matter 
> how it's built, it will still _work_ when called).  Alternatively we can 
> make comparison work (by using the exe PLT slot), in which case Alans 
> testcase will need more complications to show that protected visibility 
> currently is broken.  Alans testcase will work right now (as in showing 
> protected being broken) on data symbols.

 The way it works in the original MIPS SVR4 psABI is by using the relevant 
GOT entry's contents as the pointer, disabling lazy binding for any 
function symbols whose value is used as data rather than to make a call 
(no lazy binding stub is simply produced).  It's easy in that psABI 
because all code is PIC, even in executables -- which fulfils Cary's 
earlier postulate for protected symbol accesses.

 For non-PIC code the necessary arrangement can be made by the compiler 
based on symbol annotation (also proposed by Cary), or failing that a 
link-time fixup can be made, possibly branching to a thunk generated out 
of line if the sequence required to load a GOT entry is longer than the 
original absolute sequence (proposed by Alan).  I think this approach 
should work with x86 even, as its branch instruction has a single-byte 
opcode and a signed 32-bit span, so it certainly does not require more 
code space than any relocated instruction using the absolute or 
PC-relative addressing mode.

  Maciej