This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Argument pointers, dwarf and prologue analysis
It seems to me that the real problem is that the Dwarf debugging info
doesn't accurately describe where the bar's arguments live after the
call to foo. That is, when you return from foo, since r20 is
caller-saved, its value is unknown, and it's incorrect for the
debugging info to claim that the debugger can find the variables
relative to its value.
Yeah, I filed a gcc bug about this yesterday....
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>
randolph