Re: Preventing preemption of 'protected' symbols in GNU ld 2.26

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

On Thu, 24 Mar 2016, Cary Coutant wrote:

> - Arguing that protected means that the definition is in the same
> module but its address might be external is absurd. The *only* reason
> for the gABI to make that guarantee is so the compilers can optimize
> the code based on the knowledge that the symbol can't be pre-empted.

 For the record, SGI's original 64-bit MIPS psABI document[1], which is 
where the concept of symbol's export class aka visibility came from first, 
before having been adopted by the gABI, has these notes on the semantics 
of protected symbols:

"References to protected symbols (and hence to hidden or internal symbols) 
may be optimized by using absolute addresses in executables or by assuming 
addresses to be relatively nearby."

and:

"An R_MIPS_JALR relocation is intended for optimization of jumps to 
protected symbols, i.e. symbols which may not be preempted.  The word to 
be relocated is a jump (typically a JALR) to the indicated symbol.  If it 
is not a preemptible symbol (and therefore defined in the current 
executable/DSO) the relocation is a request to the linker to convert it to 
a direct branch (typically a JAL in the main executable, or a BGEZAL in 
DSOs if the target symbol is close enough).  The linker must check that 
the symbol is not preemptible before performing the relocation, but no 
action is required for correctness -- this is strictly an optimization 
hint."

which clearly indicate the intent for protected symbols to be defined 
locally, in the same way as hidden and internal symbols are, with the 
exception of additionally being exported.  You can't use a BGEZAL 
instruction (which is a direct branch with a limited signed 18-bit range)
if its target is moved outside the DSO it's in.

References:

[1] "64-bit ELF Object File Specification, Draft Version 2.5"
    <http://techpubs.sgi.com/library/manuals/4000/007-4658-001/pdf/007-4658-001.pdf>

  Maciej