Re: Argument pointers, dwarf and prologue analysis

[Jim Blandy <jimb@red-bean.com>]

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.

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.

But I think it's clear that the locations of the variables in the
debug info is incorrect.  There's all kinds of heuristic crud in
gcc/dwarf2out.c where it tries to figure out the right register to use
as the base for variable locations (maybe I'm thinking of the way the
CFI code chooses a CFA register; I don't really remember), but it
seemed like it could be easily confused by the use of temporaries like
r20 in the example you posted.