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

[Daniel Jacobowitz <drow at false dot org>]

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
the gABI, if so?

> > > > 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.

-- 
Daniel Jacobowitz