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: Joe Groff <jgroff at apple dot com>
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, Binutils <binutils at sourceware dot org>
- Date: Mon, 28 Mar 2016 15:38:01 -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> <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>
>>> Did you look at what the costs were in startup time and dirty pages by using
>>> copy relocations? What do you do if the size of the definition changes in a
>>> new version of the library?
>>
>> There wouldn't be a measurable cost in dirty pages; the copied objects
>> are simply allocated in bss in the executable.
>
> 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.
-cary