This is the mail archive of the
mailing list for the binutils project.
Re: Preventing preemption of 'protected' symbols in GNU ld 2.26
- From: "Maciej W. Rozycki" <macro at imgtec dot com>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, <gnu-gabi at sourceware dot org>, Ramana Radhakrishnan <ramana dot gcc at googlemail dot com>, Jeff Law <law at redhat dot com>, Cary Coutant <ccoutant at gmail dot com>, Joe Groff <jgroff at apple dot com>, Alan Modra <amodra at gmail dot com>, Binutils <binutils at sourceware dot org>, nd <nd at arm dot com>, Rich Felker <dalias at libc dot org>
- Date: Sat, 16 Apr 2016 00:59:17 +0100
- Subject: Re: Preventing preemption of 'protected' symbols in GNU ld 2.26
- Authentication-results: sourceware.org; auth=none
- References: <CAMe9rOq4CH1C5QhodxHPBteMx3ryO+SOn0awip6SuqG25+PBQg at mail dot gmail dot com> <57111A0F dot 6030507 at arm 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
"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."
"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
 "System V Application Binary Interface - DRAFT - 10 June 2013",
The Santa Cruz Operation, Inc., "Symbol Table",