On Mon, Apr 18, 2016 at 11:51 AM, Jakub Jelinek <ja...@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 <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. > > 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.
