CRIS port; frame cleanup crash
Andrew Cagney
cagney@gnu.org
Thu Feb 12 20:06:00 GMT 2004
> Ok, take two on trying to update the CRIS port to the new frame handling mechanism. I'm planning to hook in the DWARF CFI frame unwinder, but I don't know if that affects any of the other stuff I'm going to have to do. (I'm going to have to update to the new dummy stuff later, but I was hoping I could do that separately.)
CRIS is already using generic dummy frames so it should be in good
shape. The only potential got-ya is with unwind_dummy_id - you'll need
to check that the correct ID is returned.
> Thanks in advance for any answers to questions, or comments on what I've understood or misunderstood amongst all of this (or even pointers to information I might have missed).
>
> First of all, what does "unwind" mean in the frame context? I know it sounds silly, but I've been trying unsuccessfully to wrap my head around that word. Is there some fundamental thing I may have missed concerning the new frame handling, or can I just replace "unwind" with "dig out" in my head?
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.
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".
> About the struct unwind_cache: looking at the other architectures, I'm still not sure what I need in this struct. (I'm guessing stuff from the old struct frame_extra_info should go here if still needed.) Is there a recommended starting point for this struct? Some of the common members between architectures' unwind caches seem to be:
Yes, frame_extra_info is a very good starting point. "init_saved_regs"
is also a very a good starting point for the new cache init code.
> prev_sp: Most comments say "The previous frame's inner most stack address. Used as this frame ID's stack_addr." So would that be the what the stack pointer was when the current frame was entered?
Probably :-(
The i386 call instruction adjusts the SP leading to:
/* Now that we have the base address for the stack frame we can
calculate the value of %esp in the calling frame. */
cache->saved_sp = cache->base + 8;
> base: Is this "base" as in "base for local variables" or does it refer to something else? Most architectures seem to set this to the frame's frame pointer.
Thats correct.
> sp_offset and size I think I understand: how much the stack pointer has been changed so far in the frame, and how much stack space was allocated in this frame (absolute value of sp_offset) so far.
that's correct
Also:
struct trad_frame_saved_reg *saved_regs;
(from mips et.al.) which can help simplify the implementation of
register unwind.
Andrew
More information about the Gdb-patches
mailing list