This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Xtensa port
- From: Daniel Jacobowitz <drow at false dot org>
- To: Maxim Grigoriev <maxim at tensilica dot com>
- Cc: gdb at sourceware dot org, Marc Gauthier <marc at tensilica dot com>, Bob Wilson <bwilson at tensilica dot com>
- Date: Sat, 23 Sep 2006 10:26:50 -0400
- Subject: Re: Xtensa port
- References: <45142A88.7000805@hq.tensilica.com> <20060922190726.GA8221@nevyn.them.org> <45147F94.4020701@hq.tensilica.com>
On Fri, Sep 22, 2006 at 05:28:04PM -0700, Maxim Grigoriev wrote:
> I need an FP number. And, the most reliable source for this information
> is DWARF data.
You're relying on the presence of DWARF symbolic debug information, and
yet you can't use DWARF-2 unwinding (.debug_frame, dwarf2-frame.c) and
avoid the issue entirely? And you have no way to determine this
reliably from instruction scanning, like other ports do (see
prologue-value.c)? I'd recommend either in preference to this.
I can't tell you how much work either would be, because I don't
know much about Xtensa.
The problem with using DW_AT_frame_base is that there's no guarantee
it is related to what you want it to be in this context. The compiler
has a lot of freedom in what it places there; it's only meaningful
in context of local variable locations in the same frame. For
instance, you're completely ignoring any bias.
> If there is no such "utility" request ( which I thought is the case ),
> I'd need to introduce it. That would be an update to the generic part of
> GDB. And, I was given specific instructions to avoid any updates to the
> generic code, when I submit an architecture port.
I don't know why. They should generally be done separately, with
individual explanations, but hacking around the GDB core instead of
fixing it is generally frowned upon.
--
Daniel Jacobowitz
CodeSourcery