This is the mail archive of the
mailing list for the GCC project.
Re: Preventing preemption of 'protected' symbols in GNU ld 2.26 [aka should we revert the fix for 65248]
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Michael Matz <matz at suse dot de>
- Cc: "Maciej W. Rozycki" <macro at imgtec dot com>, Alan Modra <amodra at gmail dot com>, Richard Biener <richard dot guenther at gmail dot com>, Jeff Law <law at redhat dot com>, Cary Coutant <ccoutant at gmail dot com>, Joe Groff <jgroff at apple dot com>, Binutils <binutils at sourceware dot org>, GCC <gcc at gcc dot gnu dot org>
- Date: Mon, 18 Apr 2016 10:27:45 -0700
- Subject: Re: Preventing preemption of 'protected' symbols in GNU ld 2.26 [aka should we revert the fix for 65248]
- Authentication-results: sourceware.org; auth=none
- References: <983472E1-A1BC-4970-9CF9-0138A6BAD16D at apple dot com> <CAMe9rOqTTwirymAY6ORp6D_GnCsMc_hYEdy1NbZpG6x5vQc5DQ at mail dot gmail dot com> <6AAD87D2-90F9-4AD7-A195-AC91B76EA6AE at apple dot com> <CAMe9rOqNcYnm1YocG-m7XNDE0g68YQAGe=ULP-G98gaatpxSeA at mail dot gmail dot com> <CAJimCsHfT=cfb4kZysB2W_1HFfOq==TpP=wa47XPGB41MHmGyQ at mail dot gmail dot com> <56FB5061 dot 9010303 at redhat dot com> <20160330143421 dot GM15812 at bubble dot grove dot modra dot org> <571161D0 dot 10601 at redhat dot com> <CAMe9rOpt2Fd6RLtjr10wCHz9PVsXxtO9a0yvMR_DeHt1OK0ieg at mail dot gmail dot com> <CAFiYyc2PFQdiUj=UPY8HLv+PjwVaNpcvDW6Skp8JC4DR56MkBg at mail dot gmail dot com> <20160418144911 dot GG15088 at bubble dot grove dot modra dot org> <CAMe9rOog=FJ2Si-mUqHYoOsHVwVFcZavT4X7wQdRjRhbDDWRvQ at mail dot gmail dot com> <alpine dot DEB dot 2 dot 00 dot 1604181631420 dot 21846 at tp dot orcam dot me dot uk> <CAMe9rOoxb2RKQ3ELPu=omSxnLnH326tyXpAPkZ8G+t8edSGuxw at mail dot gmail dot com> <alpine dot LSU dot 2 dot 20 dot 1604181918110 dot 20277 at wotan dot suse dot de>
On Mon, Apr 18, 2016 at 10:23 AM, Michael Matz <firstname.lastname@example.org> wrote:
> On Mon, 18 Apr 2016, H.J. Lu wrote:
>> > reason is DSO code (also handcoded assembly) may reasonably expect to
>> > be able to load the address with a PC-relative load-address type
>> > instruction (ADDIUPC, LEA, MOVAB, etc.) and the target may not even
>> > have suitable dynamic relocations available to apply any load-time
>> > fixup if the symbol referred turns up outside of the DSO. The
>> > instruction used may have a PC-relative range limit too.
>> That is why protected visibility is such a mess.
> Not mess, but it comes with certain limitations. And that's okay. It's
> intended as an optimization, and it should do that optimization if
> requested, and error out if it can't be done for whatever reason.
> E.g. one limitation might very well be that function pointer comparison
> for protected functions doesn't work (gives different outcomes if the
> pointer is built from inside the exe or from a shared lib). (No matter
> how it's built, it will still _work_ when called). Alternatively we can
> make comparison work (by using the exe PLT slot), in which case Alans
> testcase will need more complications to show that protected visibility
> currently is broken. Alans testcase will work right now (as in showing
> protected being broken) on data symbols.
We have special treatment for pointer of protected function symbol
in ld and ld.so from day one, which, BTW, disables optimization of
pointer of protected function symbol inside the shared library.