Re: CRIS port; frame cleanup crash

[Orjan Friberg <orjan.friberg@axis.com>]

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