Re: PATCH: target/19520: protected function pointer doesn't work right

["H. J. Lu" <hjl at lucon dot org>]

On Thu, Jan 20, 2005 at 08:59:37PM -0500, Daniel Jacobowitz wrote:
> On Thu, Jan 20, 2005 at 05:56:22PM -0800, H. J. Lu wrote:
> > On Thu, Jan 20, 2005 at 08:09:30PM -0500, Daniel Jacobowitz wrote:
> > > On Thu, Jan 20, 2005 at 03:59:19PM -0800, H. J. Lu wrote:
> > > > On Thu, Jan 20, 2005 at 05:59:07PM -0500, Daniel Jacobowitz wrote:
> > > > > On Thu, Jan 20, 2005 at 02:56:47PM -0800, H. J. Lu wrote:
> > > > > > The issue is the function address of a protected function isn't
> > > > > > necessarily the same as the address of the function body nor has to
> > > > > > be in the same DSO where the function is defined. In that case, the
> > > > > > only optimization we can do is to skip PLT when branch. This
> > > > > > patch marks if a symbol is protected and also treats a protected
> > > > > > function as normal. But it will skip PLT when generating the branch
> > > > > > instruction.
> > > > > 
> > > > > Is there clear documentation of these very odd semantics somewhere? 
> > > > 
> > > > It has been that way with PLT from day 1. Basically, PLT is usually
> > > > used to redirect the function call. Linker will resolve undefined
> > > > function address to the PLT entry. To make sure function address
> > > > comprison works correctly, everyone has to agree on a unique function
> > > > address, which is the PLT entry if it will ever be used. The protected
> > > > function makes it tricky.
> > > 
> > > That doesn't answer my question :-)
> > 
> > It is covered in "Function Addresses" in the i386 psABI.
> 
> OK, now we're getting somewhere.  Is it specific to the i386 psABI? 
> Do other targets have the same semantics?  Should it be documented in

I think the x86_64 psABI follows the i386 psABI on this. The ia64 psABI
has "official function descriptor", which addresses this issue. You
always get the official function descriptor for function address on
ia64. I am not sure about others. If I have to guess, all psABIs with
PLT may have this issue.

> the gABI, if so?

The gABI doesn't talk about the implementation of dynamic linking.

> 
> > > > > How about test cases?
> > > > > 
> > > > 
> > > > Is there a place I can add it? I need to build a shared library,
> > > > link a main against it and run the main.
> > > 
> > > Binutils has a number of C tests like these already.  They don't run
> > > when cross, but they're better than nothing.
> > 
> > But it tests ld, not gcc. It has
> > 
> > asm (".protected visibility");
> > 
> > int
> > visibility ()
> > {
> >   return 2;
> > }
> > 
> > It will make sure that ld does the right thing regardless what gcc
> > does. It doesn't make senses that "make check" fails because of gcc
> > gets it wrong. Besides, not all gcc support visibility.
> 
> Then come up with somewhere else to put the test, if you object to
> adding it to the LD tests.  I think it is a very bad idea to add this
> much code for an unintuitive behavior without testing it anywhere.

I will try to add something to gcc.misc-tests.


H.J.