Re: Argument pointers, dwarf and prologue analysis

Randolph Chung
2005-11-21T10:32:26Z

> 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