This is the mail archive of the
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: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: "Maciej W. Rozycki" <macro at imgtec 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 10:08:57 -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>
On Mon, Apr 18, 2016 at 10:03 AM, Maciej W. Rozycki <email@example.com> wrote:
> 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
Sorry, this isn't how function pointer works on x86.
> 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.