Hi Daniel and GDB maintainers,

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

Yes, it works fine.

I've attached a modified patch.

CHANGELOG:

gdb/

2006-10-05  Maxim Grigoriev  <maxim@tensilica.com>

   * NEWS: New port to Xtensa.
   * Makefile.in: Add dependencies for Xtensa files.
   * configure.tgt (xtensa*, xtensa*-*-elf*): New.
   * configure.host (xtensa*-*-elf*): New.
   * config/xtensa/xtensa.mt: New file.
   * xtensa-config.c: New file.
   * xtensa-tdep.h: New file.
   * xtensa-tdep.c: New file.

gdb/doc/

2006-10-05  Maxim Grigoriev  <maxim@tensilica.com>

   * gdb.texinfo: (Contributors): Add contributors of Xtensa port.

Maxim Grigoriev
Tensilica, Inc.
3255-6 Scott Boulevard
Santa Clara, CA 95054-3013
(w) 408-566-1770


Daniel Jacobowitz wrote:
> 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?
>
>