This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Preventing preemption of 'protected' symbols in GNU ld 2.26
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Cary Coutant <ccoutant at gmail dot com>
- Cc: Joe Groff <jgroff at apple dot com>, Binutils <binutils at sourceware dot org>
- Date: Mon, 28 Mar 2016 05:11:53 -0700
- 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, Mar 24, 2016 at 11:31 AM, Cary Coutant <ccoutant@gmail.com> wrote:
>>>> What relocation do you propose to access external protected
>>>> symbol on x86 for non-PIC code?
>>>
>>> Non-PIC code can still use a GOT, can't it?
>>
>> Yes.
>
> Right.
>
> Some additional thoughts:
>
> - This has nothing to do with PIE. Non-PIC-non-PIE code has been
> living with this restriction for at least 18 years (since visiblity
> was introduced into the gABI).
>
> - This has nothing to do with Ulrich's diatribe against protected
> visibility, which applies only to function symbols (and really only to
> one platform, due to how function pointer comparison works).
Copy relocation and protected symbol are mutually exclusive.
Since copy relocation is the part of x86 psABIs, it limits
protected symbol effectiveness on x86. In glibc, we add a
local alias to symbol we want to protect and access the local
alias within glibc without GOT.
> - You don't need to go full-on PIC to reference a protected data
> symbol in a shared library. You can always statically initialize a
> pointer variable, and go indirect through that ("poor-man's PIC").
>
> - We could add support for __attribute__((dllimport)) or
> __declspec(dllimport) when declaring an external variable that is
> expected to be defined in a shared library (ideally, that attribute
> ought to be placed in the library's public interface). The compiler
> can generate a PIC-style reference for that variable without
> penalizing all the other variables in the main program. This is how
> HP-UX compilers work on PA and Itanium (using #pragma external).
This is a useful feature, similar to -fno-plt, like -fgot, but only on
selective symbols.
> - Compilers could also generate tentative PIC-style references, with
> sufficient relocations to allow the linker to convert the indirect
> reference to a direct reference when possible (changing the second
> load into a nop or copy). HP-UX also does this.
I extended the x86 psABIs with relaxable GOT relocations and
implemented the similar linker optimization in ld in binutils 2.26
and gold also implemented the subset of the linker optimization.
> - Indirect references from PIC code to a protected symbol penalize the
> common case (referencing a symbol within its own module) to support
> the uncommon case, while introducing the nasty side effects of a COPY
> relocation.
>
> - COPY relocations are evil. They bind an application to a specific
> version of a shared library's ABI, and introduce a hidden startup
> cost. If we're going to make any changes, we should be moving towards
> elimination of COPY relocations, rather than disabling features that
> were designed to improve performance.
Copy relocation can improve performance. Google enabled copy
relocations for PIE in ld/gold and GCC to improve prefomance by
up to 5%:
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01215.html
It is in GCC 5.
> - 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.
One possible solution:
1. Compiler accesses protected symbols without GOT in PIC mode
and marks object files no-copy-relocation-against-protected-symbol.
2. Compiler accesses external symbols with GOT in non-PIC mode.
3. Linker marks shared object with no-copy-relocation-against-protected-symbol
if any input files have no-copy-relocation-against-protected-symbol
marker.
4. Linker optimizes out GOT access if symbol is defined locally
in executable.
5. ld.so checks no-copy-relocation-against-protected-symbol marker
on shared object to avoid copy relocation against protected symbol
at run-time.
--
H.J.