This is the mail archive of the
mailing list for the GDB project.
Re: Harvard proposal
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
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.