Re: Harvard proposal

[Andrew Cagney <ac131313@cygnus.com>]

Per Bothner wrote:
> So we need to agree what CORE_ADDR is.  If most people think that
> ultimately CORE_ADDR should be a struct, it is because CORE_ADDR is
> the data type that gdb uses internally to represent an address.  So
> either I've misunderstood you, or you got it backwards:
> ADDR_IN_REAL_DATA and ADDR_IN_REAL_INSN take an integer argument and
> *return* a CORE_ADDR; they do not *take* CORE_ADDRs.

A CORE_ADDR is a cannonical address within the target address space.  A
CORE_ADDR should, in theory, be able to identify every target byte (or
if someone gets it working - word).

The definition was developed in part to address targets that intermixed
32 and 64 bit ISA modes with 32 and 64 bit debug/object formats (read
mips64 in elf32).   Since every pointer, symbol value, ... moving in
towards GDB is eventually converted into a cannonical CORE_ADDR direct
comparisons between addresses from different sources (PC, symtab) are
made possible.

Nick Duffek wrote:
> I agree.  The problem is that CORE_ADDR has multiple personalities:
[....]
>  (2) An integer wide enough to hold a real hardware address.  This is
>       what ADDR_IN_REAL_* expects as a CORE_ADDR parameter.

GDB has several types.  CORE_ADDR, LONGEST, DOUBLEST, .... CORE_ADDR and
LONGEST are used pretty interchangably - they are both large integers so
there is nothing, other than, convention, to stop people doing this.

However, as with traditional C, I'd suggest following the convention of
CORE_ADDR (void*) for pointers and LONGEST (long) for offsets.

	Andrew