Xtensa GDB port -- revised patch
Maxim Grigoriev
maxim@tensilica.com
Thu Oct 5 23:55:00 GMT 2006
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?
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xtensa-patch.diff
Type: text/x-patch
Size: 86313 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20061005/dad0ac16/attachment.bin>
More information about the Gdb-patches
mailing list