This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC/RFA] gdb extension for Harvard architectures
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: [RFC/RFA] gdb extension for Harvard architectures
- From: Jim Blandy <jimb at zwingli dot cygnus dot com>
- Date: 03 Oct 2001 16:06:01 -0500
- Cc: Michael Snyder <msnyder at cygnus dot com>,Jim blandy <jimb at cygnus dot com>, gdb-patches at sources dot redhat dot com
- References: <3BB4D843.A92818B9@cygnus.com> <3BBA7751.8070807@cygnus.com>
Andrew Cagney <ac131313@cygnus.com> writes:
> Hmm, that d10v example made me think ...
>
> The d10v has 16 bit code pointers. They are mapped onto a core addr using:
>
> ((code_ptr) << 2) | 0x01000000)
>
> The key thing being the code pointer has a granularity of 32 bits (aka 4
> bytes).
>
> Given the expression:
>
> ((int32 @code *) func)[1]
>
> I can guess what it does. However, what about:
>
> ((int16 @code *) func)[1]
>
> I suspect that the proposed model would result in ``[1]'' and ``[0]''
> being the same location.
Since GDB represents all pointers into code space the way it does
function pointers, that's right; value_subscript just calls value_add
and then value_ind --- the equivalent of computing *(a+i). Since
there's no representation for a pointer to the second word of an
instruction, the ADDRESS_TO_POINTER method ends up throwing away the
bits the subscript had affected.
Note that a similar problem occurs already:
(gdb) print main
$1 = {int ()} 0x101405c <main>
(gdb) print main + 1
$2 = (int (*)()) 0x101405c <main>
(gdb) print main + 2
$3 = (int (*)()) 0x101405c <main>
(gdb) print main + 3
$4 = (int (*)()) 0x101405c <main>
(gdb) print main + 4
$5 = (int (*)()) 0x1014060 <main+4>
(gdb)
Note that the first four values are all the same. If you handed that
expression to x/i, you'd be unhappy.
So this is simply another existing problem, which we don't solve.
Note, however, that our proposal makes it *possible* to solve this
problem in a coherent way. Since `int16 @code *' values never exist
on the target, GDB can represent them however it likes without
breaking the rule that `GDB always represents values in target form'.
We'd need to add some new logic for arch-dependent conversions between
pointer types, but at least it could be done.