From: Maxim Grigoriev <maxim@tensilica.com>
To: gdb@sourceware.org, Daniel Jacobowitz <drow@false.org>,
Marc Gauthier <marc@tensilica.com>,
Bob Wilson <bwilson@tensilica.com>
Subject: Re: Xtensa port
Date: Sat, 23 Sep 2006 00:28:00 -0000 [thread overview]
Message-ID: <45147F94.4020701@hq.tensilica.com> (raw)
In-Reply-To: <20060922190726.GA8221@nevyn.them.org>
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
next parent reply other threads:[~2006-09-23 0:28 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <45142A88.7000805@hq.tensilica.com>
[not found] ` <20060922190726.GA8221@nevyn.them.org>
2006-09-23 0:28 ` Maxim Grigoriev [this message]
2006-09-23 14:26 ` Daniel Jacobowitz
2006-09-28 1:15 Maxim Grigoriev
-- strict thread matches above, loose matches on Subject: below --
2006-09-22 18:30 Maxim Grigoriev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45147F94.4020701@hq.tensilica.com \
--to=maxim@tensilica.com \
--cc=bwilson@tensilica.com \
--cc=drow@false.org \
--cc=gdb@sourceware.org \
--cc=marc@tensilica.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox