Re: RFA: distinguish between pointers and addresses

[Jim Blandy <jimb at zwingli dot cygnus dot com>]

I've committed this patch, with everyone's approval but Jeff Law.  The
hppa-tdep.c changes are cosmetic, so I think it'll be okay.

The way is now clear to clean up the GDB_TARGET_IS_D10V stuff.  I
can't do this immediately, so in case someone else gets to it first,
here's what needs to happen:


At the moment, the D10V port claims that pointers are 32 bits long,
even though the target thinks they're 16 bits long.  As you might
guess, this has messy consequences.  If you search for
GDB_TARGET_IS_D10V in src/gdb, every hit is a piece of code
compensating for that.

So why does the D10V port work this way?  There are two reasons:

- The D10V has separate address spaces for code and data.  Any given
  16-bit pattern could refer to either of two distinct locations,
  depending on whether you use it as a code pointer or a data pointer.

- Furthermore, since all D10V instructions are 32 bits long, and
  must be naturally aligned, the bottom two bits of every D10V code
  address are zero.  Rather than waste two bits in every code address,
  the D10V declares that a code pointer is an addresses shifted right
  two bits.  Thus, it can address 64kb * 4 == 256kb of code space 
  with only sixteen bits.

To deal with this, GDB invents a kind of "virtual address space".
Addresses in the range 0x2000000 -- 0x200ffff refer to the 64kb of
data space, and addresses in the range 0x1000000 -- 0x103fffc refer to
32-bit instructions in the 256kb code space.  This just happens to
match the convention used by the D10V monitor / stub, so standard GDB
functions like read_memory_integer and such work properly, given these
addresses.

The problem is that these "virtual addresses" don't fit in real D10V
pointers.  In order to store these in `struct value' objects, GDB
needs more than 16 bits.  Since the size of a `struct value' object's
buffer is determined by its type, GDB therefore needs to lie about the
size of pointer types.

There's also another problem: the data carried in a `struct value' is
supposed to be in target format.  For every processor other than the
D10V, they're the bits fetched directly from target memory, following
the target's word size and endianness.  However, because we munge raw
D10V addresses into our "virtual addresses", we've broken that rule.
I'm not sure this causes problems, but it seems bad.  It's certainly
not what you'd expect.


However, now that we have ADDRESS_TO_POINTER and POINTER_TO_ADDRESS
hooks, we don't need to play this game at all.  ADDRESS_TO_POINTER
gives the architecture-specific code an address and a type, and
expects it to produce an appropriate target-format pointer;
POINTER_TO_ADDRESS gives arch-specific code a target-format pointer
and a type, and expects it to produce an address.

So the D10V code can continue to use the "virtual addresses" as
expected by the stub, and simply define ADDRESS_TO_POINTER and
POINTER_TO_ADDRESS functions which convert between 16-bit values and
virtual addresses, after checking whether the type is a function
pointer or a data pointer.  Pointers can become 16 bits long, as they
should be, and all the GDB_TARGET_IS_D10V tests in the
architecture-specific code can go away.