From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Duffek To: per@bothner.com Cc: gdb@sources.redhat.com Subject: Re: Harvard proposal Date: Sat, 10 Feb 2001 17:11:00 -0000 Message-id: <200102110117.f1B1Hpp11155@rtl.cygnus.com> References: X-SW-Source: 2001-02/msg00110.html On 10-Feb-2001, Per Bothner wrote: >The word "REAL" is poorly chosen. Is a "REAL" address an integer? In my patch, it's an abstract data type containing a hardware address and supporting the following operations: (1) convert to a human-readable string (2) write to a register or memory location However, thinking more about the cut-and-paste issue raised in another thread, it might be nice for GDB to output as well as input some addresses using one of the proposed disambiguating syntaxes. That means (1) would require an address plus address space information, whereas (2) requires just the adddress. So: >Thus "user-visible" and "hardware" are two different things. I agree. It should be easy to split USER from REAL. >> OBJ symbol and entry-point addresses in object files > >What is this? File position from start of file? It depends on the linker. For Harvard architectures, GNU ld usually does the same address translation that GDB does, but that's not necessarily true of all linkers. >(Why should anyone except the object file reader care?) Indeed, the only parts of GDB that use the ADDR_*_OBJ* macros are the parts that extract information from object files. But those parts aren't all in one file, so it's useful to have a generic set of ADDR_*_OBJ* macros. >> REMOTE addresses specified to remote target for memory I/O > >How is this different from REAL? remote.c doesn't know about multiple address spaces. Therefore, when it sends an address to the board/simulator/whatever, address space information must be encoded in the address. By contrast, REAL does not contain address space information. There may need to be different macros to deal with targets other than remote.c, so maybe an addition to the target vector is needed instead of ADDR_*_REMOTE*. >> ADDR_IN_GDB_INSN (CORE_ADDR addr) >> Return internal gdb address ADDR converted to an internal gdb >> instruction address if it isn't one already. > >I have no idea what this is supposed to be. It converts a gdb-internal data CORE_ADDR to a gdb-internal instruction CORE_ADDR. This is needed because sometimes GDB can't make a good guess about whether a CORE_ADDR should be an instruction or data until well after the CORE_ADDR is created. For example, decode_line_1() calls parse_and_eval_address_1(), which doesn't know anything about address spaces and therefore picks the data space as a default. But decode_line_1() knows that line numbers are in the instruction space, so it uses ADDR_IN_GDB_INSN to convert the data address returned by parse_and_eval_address_1() to an instruction address. After adding a disambiguator such as ":", ADDR_IN_GDB_INSN might be unnecessary. >I think you're starting at the wrong end. The lesson of thirty years >of programming methodology is: Start with the data types (or objects). I think there's general agreement on the long-term goal of converting CORE_ADDR to a struct. But that's a very difficult problem, and it'll take some time to get right. This patch is useful now, and I think it's a big step in the right direction toward the struct core_addr goal. >ADDR_IN_REAL_DATA and ADDR_IN_REAL_INSN take an integer argument and >*return* a CORE_ADDR; they do not *take* CORE_ADDRs. I agree. The problem is that CORE_ADDR has multiple personalities: (1) An abstract data type that gdb uses internally to represent an address. This is what ADDR_IN_* returns. (2) An integer wide enough to hold a real hardware address. This is what ADDR_IN_REAL_* expects as a CORE_ADDR parameter. Long-term, we need to come up with typedefs to distinguish between the two. >> ADDROFF_OUT_REAL (CORE_ADDR addr, CORE_ADDR offset) >> Return internal gdb address OFFSET from ADDR converted to a real >> address offset. > >An "offset" needs to be a different datatype from a CORE_ADDR. Not necessarily: >An offset is just a plain integer (and perhaps a "unit" e.g. >bit/byte/word). And an address space, so that it's bit-shifted appropriately when converted to a user or real address. In other words, it's a relative CORE_ADDR rather than an absolute one. I'm not sure it's necessary to add a new typedef to distinguish between the two. Nick