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 [aka should we revert the fix for 65248]
- From: "Maciej W. Rozycki" <macro at imgtec dot com>
- To: Michael Matz <matz at suse dot de>
- Cc: "H.J. Lu" <hjl dot tools at gmail 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 18:57:27 +0100
- 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, 18 Apr 2016, Michael Matz wrote:
> 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.
The way it works in the original MIPS SVR4 psABI is by using the relevant
GOT entry's contents as the pointer, disabling lazy binding for any
function symbols whose value is used as data rather than to make a call
(no lazy binding stub is simply produced). It's easy in that psABI
because all code is PIC, even in executables -- which fulfils Cary's
earlier postulate for protected symbol accesses.
For non-PIC code the necessary arrangement can be made by the compiler
based on symbol annotation (also proposed by Cary), or failing that a
link-time fixup can be made, possibly branching to a thunk generated out
of line if the sequence required to load a GOT entry is longer than the
original absolute sequence (proposed by Alan). I think this approach
should work with x86 even, as its branch instruction has a single-byte
opcode and a signed 32-bit span, so it certainly does not require more
code space than any relocated instruction using the absolute or
PC-relative addressing mode.
Maciej