CRIS port; frame cleanup crash
Orjan Friberg
orjan.friberg@axis.com
Sat Feb 14 13:38:00 GMT 2004
Andrew Cagney wrote:
>
> The term "unwind" is used by the dwarf-2 specification.
> http://www.eagercon.com/dwarf/dwarf3std.htm
> it includes a working example in the appendix.
Excellent, thanks a lot. Section 6.4 regarding Call Frame Information
cleared up some of the confusion regarding unwinding.
> The important thing is to "dig out" the register from the correct frame.
> frame_unwind_register (next_frame, "pc") will "dig out" the PC from the
> next frame (often found in next frame's link register) returning the
> value as it should be in "this_frame".
This explanation has me slightly puzzled. I gather from the code that
"PC" refers to the current program location within a frame, and not an
actual CPU register. Is "next" synonymous with "outer" in your
explanation above? (Perhaps a stupid question; maybe unwind by
definition works on the outer frame/caller.) And "link register" I
assume is the equivalent of a subroutine return pointer.
Approaching it from another direction, what would be a good test to see
if the unwind code works correctly? At present, step (into function
calls), next (over function calls), finish, and backtrace seem to work
ok for both leaf- and non-leaf-functions (for CRIS the prologue differs
slightly as the SRP isn't pushed in case of a leaf function). Is there
any particular existing testcase that would be good at detecting errors
in the frame code?
Another question: should I hook in the dwarf-2 frame sniffer from the
very beginning? Or wait until the other stuff seems to be working ok?
Thanks,
Orjan
--
Orjan Friberg
Axis Communications
More information about the Gdb-patches
mailing list