Re: Xtensa GDB port -- revised patch

[Daniel Jacobowitz <drow@false.org>]

On Wed, Sep 27, 2006 at 06:06:52PM -0700, Maxim Grigoriev wrote:
> After some investigation, it turns out that the get_fp_num() function, 
> which was "grubbing around in the private data structures of the symbol 
> reader", is not needed at all.  Perhaps that code was left over from an 
> earlier version of GDB. Stack unwinding on Xtensa can be done using the 
> register windows -- it requires neither prologue analysis to find the 
> frame pointer nor DWARF unwind info.  The only thing the get_fp_num() 
> function was used for was identifying frames, but it seems like we can 
> just use the stack pointer for the frame ID.  (Is that right?)  I've 
> changed the code to do this and it appears to work fine: no DejaGnu 
> regression has been detected, and manual testing on alloca-tests hasn't 
> exposed anything.

I'm not entirely sure, but I think you're off by one frame.  The goal
is to use a long-lived value which will never change during a single
execution of a function.  So we normally use the DWARF concept of a
"Call Frame Address" - the stack pointer at the time of the call.
If you use the current stack pointer for the frame, then you
are liable to change the ID during execution of a function, while
single stepping.  Normally this isn't a big problem; I don't remember
offhand what the usual symptoms are.

Can you use the previous frame's stack pointer instead?  Is that going
to work?

-- 
Daniel Jacobowitz
CodeSourcery