This is the mail archive of the gdb@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: Argument pointers, dwarf and prologue analysis


On Mon, Nov 21, 2005 at 06:32:11PM +0800, Randolph Chung wrote:
> >I don't think that the wacky idea about recovering r20's value by
> >looking at the call site will work.  I mean, if r20 is a scratch
> >register, you have no way of knowing that it hasn't been used for
> >something else since the function was entered, right?  I admit I don't
> >really understand that.
> 
> Well, for gcc, preceeding every call will be a setting of the argument 
> pointer is a relative offset to the stack pointer. We only need to know 
> the value of r29 and r20 during the prologue, so I would argue that if 
> we know the value of r29 immediately before the call (at the call site), 
> then prologue analysis will be able to tell you where the arguments are 
> stored.
> 
> that is, there will always be:
> 
> caller:
> 	...
> 	ldo -48(%sp), %r29
> 	...
> 	bl callee, %r2
> 
> callee:
> 	...
> 	ldo -64(%r29), %r20
> 	stw %arg0, 4(%r20)
> 	...
> 	<after prologue insns>

So you're saying you have to do (A) backwards code analysis from the
call site to compute r29, and then (B) forward code analysis from the
function start to compute r20 relative to r29, and then (C) use dwarf
debug information to find arguments relative to r20, and then (D) hope
that GCC doesn't decide to use r20 for something different, since it
doesn't seem to be a traditional "frame pointer"?  There's a lot more
prayer in that method than there really ought to be.  And GCC will
probably take some severe liberties with where the set of %r29 is, so
I'm skeptical that you can do the call site analysis.

How does GDB cope today?  A lot of guessing and failing?

I'd recommend ignoring the call site/ABI bits.  They're too unreliable.
The real problem is that you can't recover %r20.  You're thinking in
terms of finding the offset relative to the CFA where these things are
stored, which is why you've got a solution that relies on analyzing the
caller.  But think about the problem in terms of the callee for a
moment.  The function doesn't care what the offset relative to the CFA
is.  It cares what the offset relative to the incoming %r29 and later
%r20 is.  And then, if it makes any calls, it had better still know
where its own arguments went!  So that should be in the debug info
somehow.

We've got dwarf unwind information to play with now.  Even with the new
additions in dwarf3, it's not so good at representing what you need. 
I'd need to see a larger example to know how we could, or couldn't, do
this.

-- 
Daniel Jacobowitz
CodeSourcery, LLC


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