This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

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


H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]