This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC 2/3] Record function descriptor address instead of function address in value
- From: Yao Qi <qiyaoltc at gmail dot com>
- To: "Maciej W. Rozycki" <macro at imgtec dot com>
- Cc: Ulrich Weigand <uweigand at de dot ibm dot com>, "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Fri, 28 Oct 2016 17:20:35 +0100
- Subject: Re: [RFC 2/3] Record function descriptor address instead of function address in value
- Authentication-results: sourceware.org; auth=none
- References: <20161017155133.A9B8711C257@oc8523832656.ibm.com> <alpine.DEB.2.00.1610180255070.31859@tp.orcam.me.uk>
On Tue, Oct 18, 2016 at 3:27 AM, Maciej W. Rozycki <macro@imgtec.com> wrote:
>
> Agreed. I'd keep `disass main+4,+4' and `x/i main' (or `x/x main', etc.,
> for that matter) as they are now and consistent with `disass main', if
> possible. These would indeed have to be special as we don't actually want
> to see the ISA bit set in instruction addresses in disassembly either, as
> they are interpreted as memory data rather than execution addresses there.
>
> For descriptor access, which may undoubtedly be useful sometimes I'd
> suggest using `disass &main+4,+4' and `x/i &main', which would be
> consistent with the interpretation of function pointers elsewhere (of
> course `p main' and `p &main' would roughly be equivalent). Thoughts?
Right, "main" in "x/i main" means the function address of main; "&main"
means the pointer to function main. However, I am not sure "p main"
and "p &main" is equivalent in terms of output.
>
> Overall I like the proposal and if this goes forward I will see if we can
> adapt the MIPS backend to use this approach as well, addressing the issues
> we still have remaining, such as confusing instruction addresses and wrong
> instruction data shown with `disass /r'. We have a little complication in
> that we have the ISA bit set in line information, so that would have to be
> stripped in DWARF record processing, but it should be much easier to do
> with a single hook in place than the complicated processing now required
> to copy ISA bit annotation from the symbol table (msymbols), the hooks to
> handle which we'll then be able to drop from our DWARF machinery.
>
At the very beginning, I wanted to follow the MIPS approach in ARM,
but I realized some issues when writing the patch. Then, I switched to
the approach I am proposing in this thread. If the ISA bit plus function
address is regarded as a function descriptor, this approach should be
able to handle all of them (ppc64, arm and mips) correctly (and
cleanly, I hope).
--
Yao (齐尧)