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

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

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.

> 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:
<https://sourceware.org/ml/binutils/2016-03/msg00368.html> for my earlier 
comment.

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