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: Jakub Jelinek <jakub at redhat dot com>
- Cc: Michael Matz <matz at suse dot de>, "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 12:28:27 -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: <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> <CAMe9rOpTRq1gATYTW9ts4XNOq5ziQKp+Gkuw2QEDZWe6i-dcyA at mail dot gmail dot com> <20160418185151 dot GL2920 at laptop dot zalov dot cz>
On Mon, Apr 18, 2016 at 11:51 AM, Jakub Jelinek <firstname.lastname@example.org> wrote:
> On Mon, Apr 18, 2016 at 10:27:45AM -0700, H.J. Lu wrote:
>> On Mon, Apr 18, 2016 at 10:23 AM, Michael Matz <email@example.com> wrote:
>> > Hi,
>> > 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.
> But maybe that is the mistake. Doing this makes protected visibility
> no longer a userful optimization for anything, it is usually more expensive
> than normal visibility, so it is generally a pessimization nobody should
> really use.
> Compared to this, having a protected-like visibility which doesn't care
> about function pointer comparisons would be generally useful to many
> projects, and e.g. glibc is heavily using it itself (using hacked up
> macros). Generally it could be even implementable just on the compiler side
> and leave the badly designed "protected" to keep what it used to do (i.e.
> revert the change) and hope or actively suggest to users that if they ever
> think of this "protected" visibility, they are always doing something wrong.
It is a good idea to revisit the whole protected visibility issue on x86
in terms of C/C++ languages, x86 psABIs, compiler, ld and ld.so.