This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB 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] Strange stepping behaviour with ppc32 with secure PLTs


On Sun, May 14, 2006 at 12:01:41AM +0930, Alan Modra wrote:
> 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.

Hmm.  Do they still end up in a section named .plt?  That'd probably
make it easier for both gdb and binutils.

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

There's two things necessary to make stepping and shared libraries play
nice.

1.  Be able to unwind from the stub, so that we can see we've stepped
into something.  We need symbols or some other similar code reading in
order to make this work.

2.  Be able to identify this debug-info-less block of code as a stub,
so that we can skip it if we're going to step into a shared library
function that has debug info.  I pointed Paul at the right function for
handling this earlier, but it's somewhat orthogonal.

-- 
Daniel Jacobowitz
CodeSourcery


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