Xtensa port

Xtensa port

[Maxim Grigoriev]

I just sent an updated patch with the following comments:

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.

The other suggestions that I've received so far were easy to use and 
I've done that.  By the way, I also removed the line to use the 
dwarf2_frame_sniffer, because DWARF unwind info is not currently used 
for Xtensa.

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

Re: Xtensa port

[Maxim Grigoriev]

Hi Daniel,

I hope I know how to handle all your other comments. But, this one is 
not easy:
>> +/* get_fp_num() returns the register number of the frame pointer for the frame
>> +   specified by pc.  Depending on how the function was compiled, the fp could
>> +   be either a1 (sp) or another register set by the compiler.
>> +   Note: it returns register number for an Ax, not for ARx.
>> +
>> +   We extract the FP register number from the DWARF info generated by the
>> +   compiler.  If anything is wrong with the DWARF info or there is no DWARF
>> +   info at all we return A1_REGNUM.  */
>> +
>> +static int
>> +get_fp_num (CORE_ADDR pc)
>> +{
>> +  struct symtab_and_line debug_info;
>> +  struct symbol *func_sym;
>> +
>> +  DEBUGTRACE ("get_fp_num (pc = 0x%08x)\n", (int) pc);
>> +
>> +  debug_info = find_pc_line (pc, 0);
>> +  /* If there is no debug info return A1.  */
>> +  if (debug_info.line == 0)
>> +    return A1_REGNUM;
>> +
>> +  func_sym = find_pc_function (pc);
>> +  if (func_sym)
>> +    {
>> +      if (SYMBOL_OPS (func_sym) == &dwarf2_locexpr_funcs)
>>     
>
> No way.  I don't know what you need this information for, but we have
> to find some way to get it that does not require grubbing around in the
> private data structures of the symbol reader
I need an FP number. And, the most reliable source for this information 
is DWARF data.

When GDB generates offsets and addresses for, say, local variables, it 
uses exactly the same technique I used here. But, it's done in a 
specific context, which is not available in xtensa-tdep.c. I was not 
able to find a clear "utility" routine to get an FP number for a given 
function. So I just implemented it. Can you give me some hints on how 
could it be done differently, please ?

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.

-- Maxim

Re: Xtensa port

[Daniel Jacobowitz]

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

Xtensa port

[Maxim Grigoriev]

Hello everybody,

I just sent a basic Xtensa port to gdb-patches@sources.redhat.com.
If maintainers can evaluate this patch I'd really appreciate it.

If anybody has questions regarding GDB Xtensa support I'd be happy to 
answer you.

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