Re: [RFC/RFA] gdb extension for Harvard architectures

Jim Blandy
2001-10-03T14:04:00Z

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
(gdb) print main + 1
$2 = (int (*)()) 0x101405c
(gdb) print main + 2
$3 = (int (*)()) 0x101405c
(gdb) print main + 3
$4 = (int (*)()) 0x101405c
(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.