Re: RFA: print addresses that are longer than pointers, take two

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

> > I recently made changes which allow GDB to handle architectures on
> > which addresses are larger than pointers.  However, the code which
> > Peter Schauer added to printcmd.c to handle unwanted sign extension
> > assumes that addresses and pointers are the same size.
> > 
> > As it turns out, this masking is unnecessary when the value being
> > printed is a genuine pointer; the sign extension won't occur, and the
> > masking is unneeded.
> 
> There is an important question here.  How should GDB internally
> represent an address obtained from C pointer values in memory when
> TARGET_PTR_BIT (ie C pointer) < ``TARGET_CORE_ADDR_BIT''?  Should it
> sign extend it (as some architectures do) or not as others do.

Here's my proposal:

On all architectures, a CORE_ADDR is a byte address.  CORE_ADDR must
be large enough to assign a distinct address to every byte on the
system --- even for machines with separate code and data spaces, word
addressing, etc.  Otherwise, it's pretty hard to figure out what
read_memory should do.  :)

Symbol addresses are always byte addresses, so CORE_ADDRs and symbol
addresses are the same thing.

On all architectures, `struct value' must always carry its contents in
target format.  If the target uses word addresses, then a `struct
value' holds a word address.  This is necessary in order for things
like pointer arithmetic and arrays to work properly.

An architecture can specify the conversions between target-format
addresses and CORE_ADDRs by defining the ADDRESS_TO_POINTER and
POINTER_TO_ADDRESS macros.  As I explained in a previous message, "Re:
RFA: distinguish between pointers and addresses" on Apr 14, these
provide everything you need to handle ports like the D10V, and the one
I just finished, but can't yet mention publicly.  It has turned out
very nicely.

The nice thing about ADDRESS_TO_POINTER and POINTER_TO_ADDRESS is that
they allow you to specify this relationship in whatever way is most
appropriate for your architecture.