Re: Harvard proposal

[Nick Duffek <nsd at redhat dot com>]

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 "<space>:", 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