This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Xtensa GDB port -- revised patch
- From: Daniel Jacobowitz <drow at false dot org>
- To: Maxim Grigoriev <maxim at tensilica dot com>
- Cc: gdb-patches at sources dot redhat dot com, Bob Wilson <bwilson at tensilica dot com>, Marc Gauthier <marc at tensilica dot com>
- Date: Wed, 27 Sep 2006 21:19:10 -0400
- Subject: Re: Xtensa GDB port -- revised patch
- References: <451B202C.3090804@hq.tensilica.com>
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