This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]