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 Mon, May 15, 2006 at 10:26:19AM +0930, Alan Modra wrote:
> In thinking about this some more, I remembered why I didn't implement
> synthetic stub syms for powerpc.  There is a really difficult problem
> with -fPIC code, which can have multiple GOTs.  The stubs for -fPIC
> -shared or -fPIC -pie code calculate the plt entry from the got pointer
> used by the calling function.  That means we might need multiple stubs
> for any given plt entry.  eg. printf called from f1 and f2 where f1 uses
> a different GOT to f2 will require two stubs and one .plt entry.  So we
> can't just start from the first stub and match one for one with plt
> entries.  Worse, code reading the stub doesn't give us a clue about the
> got pointer value.  So BFD can't match stubs to plt entries without
> finding where the stub is falled *from*, and then analysing the function
> prologue.  This is way too hard.

Can't we somehow record them in the object file, then?

If they aren't in their own section, we'd have to check for them
any time we were stopped without a symbol in .text.  And GDB doesn't
even know how to use the sizes of symbols, so it may sometimes decide
they're part of an earlier function.

> > 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.
> 
> I think code reading is the way to go on both of these.  Presumably gdb
> knows the register state for both of these problems, so finding the
> caller (from lr) isn't hard, and you reach the callee just by
> single-stepping a few insns.

I suppose it could be made to work.  It's going to be a bit nasty,
though.

-- 
Daniel Jacobowitz
CodeSourcery


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