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: Cary Coutant <ccoutant at gmail dot com>
- To: Alan Modra <amodra at gmail dot com>
- Cc: Joe Groff <jgroff at apple dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>, Binutils <binutils at sourceware dot org>
- Date: Mon, 28 Mar 2016 17:29:47 -0700
- Subject: Re: Preventing preemption of 'protected' symbols in GNU ld 2.26
- Authentication-results: sourceware.org; auth=none
- References: <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> <CAMe9rOqcw2P_ZU2u-mQ5m7wrVygLKxD3R=KwkxdpiXkeM6o_2g at mail dot gmail dot com> <BC969B3B-87A2-4238-90C8-DA2E166707AF at apple dot com> <CAJimCsGW3qY2aow_WrjeXUUH9_XUWm5=kNp7DbqdgC_=G+jLuQ at mail dot gmail dot com> <08556ECF-C47B-400E-91A2-56D338E55D86 at apple dot com> <CAJimCsGDoYVWP4WLB-vu6Gr3Lnh0DoYYrWPZYgC3MKJ7Jv0oqQ at mail dot gmail dot com> <20160328232105 dot GA15812 at bubble dot grove dot modra dot org>
>> > Wouldn't references to the symbol from within the .so need to be relocated to reference the now-canonical copy in the executable?
>>
>> No, references from within the .so would have always used the GOT.
>> Non-protected global symbols in a shared library are still
>> pre-emptible, so they are always indirect, and there's always a
>> dynamic relocation for the GOT entry. Whether the prevailing
>> definition winds up in the executable or the shared library, the
>> dynamic loader still has to bind the symbol and apply the relocation.
>
> HJ's changes to protected visibility meant compiler changes so that
> protected visibility in shared libraries is no longer seen as local.
> So yes, protected visibility symbols in shared libraries now go
> through the GOT. Prior to his changes, they were optimized to a
> pc-relative access. Joe is correct in pointing out that shared
> libraries needed a change. Bad luck if you're using an older
> compiler. Also bad luck if you want to use protected visibility to
> optimize your shared library.
>
> HJ also made glibc ld.so changes to ensure the semantics of protected
> visibility symbols remain unchanged when multiple shared libraries
> define the same protected visibility symbol.
>
> Apparently most people in the gcc and glibc communities saw these
> toolchain modifications as fiendishly clever.
I may have misunderstood the context of Joe's question, but I read it
as asking about the effect of Sri's changes to use direct references
to all symbols in PIE mode, rather than the effect of HJ's changes to
use indirect references to protected symbols in PIC mode.
In the former context, we're talking about code where protected
symbols are not often used, references from the executable to shared
library data is infrequent, and the intersection of the two is
exceedingly rare. There was a clear benefit to changing PIE code to
use GOT-relative, rather than GOT-indirect, references to data. It was
only necessary to tweak the linker to allow COPY relocations from a
PIE executable so that the infrequent references from the executable
to (non-protected) shared library data symbols would still work. Any
non-PIC references to protected symbols would have already failed
because the code had already successfully built as a non-PIE
application.
In the latter context, we're talking about penalizing access to
protected symbols within a shared library in order to support that
exceedingly rare case that already didn't work for non-PIE code. I
just don't see the value.
It's too bad that Sri's PIE changes pre-dated HJ's mov-to-lea
link-time optimization. I suspect that that optimization, all by
itself, would have reclaimed most of the lost performance that Sri
observed when turning on -fPIE, and we may never have descended into
this morass.
-cary