Re: CRIS port; frame cleanup crash

[Andrew Cagney <cagney@gnu.org>]

> 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