Re: CRIS port; frame cleanup crash

[Orjan Friberg <orjan.friberg@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.)

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?

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:

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?

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.

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.


Thanks,
Orjan

-- 
Orjan Friberg
Axis Communications