From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Michael Snyder <msnyder@cygnus.com>, Jim blandy <jimb@cygnus.com>, gdb-patches@sources.redhat.com
Subject: Re: [RFC/RFA] gdb extension for Harvard architectures
Date: Wed, 03 Oct 2001 14:04:00 -0000
Message-id: <npn138o2me.fsf@zwingli.cygnus.com>
References: <3BB4D843.A92818B9@cygnus.com> <3BBA7751.8070807@cygnus.com>
X-SW-Source: 2001-10/msg00062.html

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.