Re: Preventing preemption of 'protected' symbols in GNU ld 2.26 [aka should we revert the fix for 65248]

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Mon, Apr 18, 2016 at 11:51 AM, Jakub Jelinek <jakub@redhat.com> 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 <matz@suse.de> 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.

-- 
H.J.