Re: [CRIS] dwarf2 frame sniffer problem?

[Daniel Jacobowitz <drow@false.org>]

On Thu, Mar 11, 2004 at 04:55:04PM +0100, Orjan Friberg wrote:
> I don't know if this is related to the previous suggested problem (i.e. 
> the dwarf2 information being wrong), but I changed the test program 
> slightly to:
> 
> void bar(void) {}
> void foo(void)
> {
>   bar();
> }
> int main ()
> {
>   foo();
>   return 0;
> }
> 
> Now foo is no longer a leaf function, and thus saves the return address 
> on the stack in its prologue.  Stepping over foo ("next" in main) causes 
> a breakpoint to be set at the first instruction in foo.  After the 
> target is stopped at that instruction (which is where the return address 
> is pushed on the stack) dwarf2_frame_prev_register is called, which 
> thinks that the PC is saved on the stack (case 
> DWARF2_FRAME_REG_SAVED_OFFSET) and reads it from there.  Obviously the 
> value it reads is wrong, since the return address hasn't been pushed yet.
> 
> What's wrong here?  Is the dwarf2 debug information wrong, or should 
> dwarf2_frame_prev_register not have been called while still in the prologue?

The beauty of using the CFI data is that it _is_ supposed to work in
the prologue.  It sounds like the CFI is wrong.  Could you post both
assembly and CFI data for the same testcase?  I don't know CRIS
assembly but I imagine I can interpret it well enough to see what's
going on.

It also sounds like your DWARF2_REG_TO_REGNUM may need work, if the
unwinder thinks r16 is the return address column and GDB thinks it's an
8-bit register.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer