From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Per Bothner Cc: Nick Duffek , gdb@sources.redhat.com Subject: Re: Harvard proposal Date: Fri, 23 Feb 2001 17:25:00 -0000 Message-id: <3A970CE6.6B2D2F34@cygnus.com> References: <200102102025.f1AKPtS11061@rtl.cygnus.com> X-SW-Source: 2001-02/msg00336.html 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