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: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: 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:03:50 +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>
On Mon, 18 Apr 2016, H.J. Lu wrote:
> > Any testcase the takes the address of a protected visibility variable
> > defined in a shared library now can get the wrong answer, since you
> > can argue that any address outside the shared library is wrong
> > according to the gABI.
>
> What value should you get when taking an address of a function
> with protected visibility inside the shared library? Should it be
> pointed to the function body or its PLT entry in the executable
> which calls the function?
I think it has to be an address within the shared library itself, that is
-- depending on the particular psABI -- either the function body or its
corresponding PLT entry in the DSO, but not in the main executable. The
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.
Maciej