Re: Argument pointers, dwarf and prologue analysis

[Randolph Chung <randolph@tausq.org>]

> 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