On Mon, 18 Apr 2016, Michael Matz wrote: > 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.
The way it works in the original MIPS SVR4 psABI is by using the relevant GOT entry's contents as the pointer, disabling lazy binding for any function symbols whose value is used as data rather than to make a call (no lazy binding stub is simply produced). It's easy in that psABI because all code is PIC, even in executables -- which fulfils Cary's earlier postulate for protected symbol accesses. For non-PIC code the necessary arrangement can be made by the compiler based on symbol annotation (also proposed by Cary), or failing that a link-time fixup can be made, possibly branching to a thunk generated out of line if the sequence required to load a GOT entry is longer than the original absolute sequence (proposed by Alan). I think this approach should work with x86 even, as its branch instruction has a single-byte opcode and a signed 32-bit span, so it certainly does not require more code space than any relocated instruction using the absolute or PC-relative addressing mode. Maciej
