This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: CRIS port; frame cleanup crash
- From: Andrew Cagney <cagney at gnu dot org>
- To: Orjan Friberg <orjan dot friberg at axis dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Thu, 12 Feb 2004 15:06:55 -0500
- Subject: Re: CRIS port; frame cleanup crash
- References: <3F392591.4050409@redhat.com> <402BCCF2.601@axis.com>
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