This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: dwarf2 and frame bases
> > 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/