Re: dwarf2 and frame bases

[Randolph Chung <randolph@tausq.org>]

> > but the unwound copy is wrong too... :) i explain more below..
> 
> Then, that's a bug in the unwinder.

after a night's sleep and some more looking through the code, this is
making a bit more sense...

> > r3 is also a callee-saved register, so its contents are undefined on
> > entry to the function. so even if you were to unwind r3, you won't get
> > the right frame base.
> 
> That's your mistake.  At the first instruction of the prologue,
> unwinding r3 for the previous frame should use the copy already in
> r3; you need to be falling back to a prologue analyzer and cutting it
> off at $pc.  I thought you already were?

yes, but...

so, if you are at the first insn of the prologue, and you unwind r3, you
would get the *previous frame*'s frame base.  if you used this value to
calculate the address of your locals, you will get the value they have
in the previous frame.

sounds like it should still work (i.e it should still be a valid
address), except the hppa targer has an explicit check for when we
expect r3 to be modified but we may be in the process of changing it
(since it's a 3 insn sequence). In that case, we zero the register to
tell the unwinder not to use the value in the r3 to calculate the frame
base (it uses the stack pointer and other unwind information in that
case)

See http://sources.redhat.com/ml/gdb-patches/2004-06/msg00108.html for
more details.

i know it is kind of hacky, but the frame unwinding code is explicitly
asking "what is the frame base of this frame", and the target code is
especially tuned for that..... 

i see two possible solutions:
1) perhaps the hppa target should use some other mechanism (instead of 
   mucking with r3) to tell the next frame that the frame pointer is 
   not available.....
2) in the dwarf code, when trying to get the frame base, should we
   explicitly ask for the frame base instead of using the dwarf 
   expression? perhaps this could be something that can be overridden
   by the target, so that the default still uses the dwarf information.

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/