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: Cary Coutant <ccoutant at gmail dot com>
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, Joe Groff <jgroff at apple dot com>, Binutils <binutils at sourceware dot org>
- Date: Tue, 29 Mar 2016 13:39:00 +0100
- Subject: Re: Preventing preemption of 'protected' symbols in GNU ld 2.26
- Authentication-results: sourceware.org; auth=none
- References: <9106B2FB-BB06-413A-A04D-EEFB992784FA at apple dot com> <CAJimCsEzZ8GDByd8r9x5J9sQ__V0o1mn21FD1xLPe7OhWdikKQ at mail dot gmail dot com> <CAMe9rOqipnAMa-OeYfks6=FYRffxSrcLuJnJD=wX-PjoKcGWRA at mail dot gmail dot com> <CAJimCsFxza3TWVXorqYLa--SfUZ_LznR=m2GkJ_Mq6YZ9Ga3YQ at mail dot gmail dot com> <CAMe9rOphSdEp8mO7OpuEAVpUz-hT8eRb=6RJmaP1XWvDC_UNpQ at mail dot gmail dot com> <CAJimCsHGnHp+s4OXVMt5K=AOsz=nPqY_W7L_M0Ey5rSdK7nk1g at mail dot gmail dot com> <CAMe9rOowzNKqmgf+5A6R-BdEjv2_KAnEYO=PxUH6=MYST_Fu3w at mail dot gmail dot com> <9EFBBDCE-4054-4867-B3E9-9DFE216A234F at apple dot com> <CAMe9rOqqPVeaRZ8SPD-uoxRnHFOCGV3xXFNnDY5ez6xY8uG6hw at mail dot gmail dot com> <CAJimCsFffshMvsDoRq_33Ss8u9Y_Z4y2NKsqDbxJQuO6SyJNbg at mail dot gmail dot 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, 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."
"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
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.
 "64-bit ELF Object File Specification, Draft Version 2.5"