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

[Szabolcs Nagy <nsz at port70 dot net>]

* Maciej W. Rozycki <macro@imgtec.com> [2016-04-16 00:59:17 +0100]:
> On Fri, 15 Apr 2016, Szabolcs Nagy wrote:
> 
> > > Copy relocation and protected visibility are fundamentally incompatible.
> > > On on hand, copy relocation is the part of the psABI and is used to
> > > access global data defined in a shared object from the executable.  It
> > > moves the definition of global data, which is defined in a share object,
> > > to the executable at run-time.  On the other hand, protected visibility
> > > indicates that a symbol is defined locally in the shared object at
> > > run-time.  Both can't be true at the same time.  The current solution
> > 
> > protected visibility indicates
> > 
> >   "that references within the defining module bind to
> >   the definition in that module. That is, the declared
> >   entity cannot be overridden by another module."
> > 
> > here "definition in that module" does not mean addresses
> > at runtime, but the c language level definition.
> > (c semantics can only indicate abstract machine behaviour,
> > not relocation types and in memory layout at runtime).
> 
>  Where did you get this definition from and how do you infer this is a "c 
> language level" rather than a binary level definition?  The SVR4/ELF gABI 
> says[1]:
> 
> "A symbol defined in the current component is protected if it is visible
> in other components but not preemptable, meaning that any reference to
> such a symbol from within the defining component must be resolved to the
> definition in that component, even if there is a definition in another
> component that would preempt by the default rules."
> 
> and:
> 
> "The presence of the STV_PROTECTED flag on a symbol in a given load module
> does not affect the symbol resolution rules for references to that symbol
> from outside the containing load module."
> 
> so it clearly indicates that it is dynamic load modules (i.e. either the 
> main executable or any of its referred DSOs) that are considered here, not 
> C source-level semantics.  Besides the ELF ABI is programming language 
> agnostic, using the C language as a reference only, so it cannot really 
> consider source-level semantics.
> 

sorry, i just looked at the c extension as documented
by gcc, but the elf gabi is the right source. however
it seems to verify my interpretation.

> > so there is no conflict between copy relocation and
> > protected visibility: the definition is not overridden,
> > it's an implementation detail that the address happens
> > to be in the data section of the main executable instead
> > of the defining module.
> 
>  Both the reference above and established practice assume a protected 
> symbol must have its address within the module that defines it.  See also:

copy relocation is not another definition for the symbol
(it's an implementation detail), and symbol resolution
rules for external references are not affected, so both
constraints you cited above hold now.

> <https://sourceware.org/ml/binutils/2016-03/msg00368.html> for my earlier 
> comment.

ok, so it was intended to be an optimization (for function
symbols), but that breaks correctness for object symbols
in the presence of copy relocations.. so the optimization
is not valid: the symbol must be visible to other modules
which only works for the non-pic main module via copy relocs.

> References:
> 
> [1] "System V Application Binary Interface - DRAFT - 10 June 2013",
>     The Santa Cruz Operation, Inc., "Symbol Table",
>     <http://www.sco.com/developers/gabi/latest/ch4.symtab.html>
> 
>   Maciej