On Mon, Apr 18, 2016 at 10:23 AM, Michael Matz <m...@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.
