Re: [patch] Strange stepping behaviour with ppc32 with secure PLTs

[Alan Modra <amodra@bigpond.net.au>]

On Fri, May 12, 2006 at 06:50:44PM -0400, Daniel Jacobowitz wrote:
> Hey, Alan, Paul's pointed out that there are no synthetic symbols for
> the stubs in -msecure-plt mode.  How hard would that be to fix?

Not too hard, but messy.  The only real difficulty is finding the stubs.
We don't have any handy symbols or relocs to identify them, so that
means code reading.

We do have --emit-stub-syms to emit symbols on stubs at link time.  I
probably should have made the linker always emit the first stub sym so
we could easily find all the stubs.

> > > What do you mean by "unknown section"?
> > 
> > This is what I mean:
> > (top-gdb) p *bfd_section
> > $2 = {name = 0x1049c528 "*UND*", id = 1, index = 0, ...
> 
> That's not an "unknown" section.  That's the undefined section!  It
> means that the symbol has a value, but is marked as undefined.  This
> is typical for PLT entry stubs, but it's an implementation choice;
> I don't think the gABI has much to say about undefined symbols with
> addresses.

PLT symbols like this, ie. undefined but with nonzero value are a clue
to the dynamic linker that it needs to treat the sym specially, to make
function pointer comparisons work between an app and its shared libs.

> The right thing to do then is probably to create the synthetic symbols
> at exactly those same addresses.

No, if I understand correctly, Paul wants to use a stub symbol as a
means of letting gdb know that it is in a plt call trampoline.  Putting
the symbol in .plt won't do that for you.  Best just teach gdb what a
plt call stub looks like.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre