Harvard proposal

Harvard proposal

[Nick Duffek]

Recently, I took a stab at converting CORE_ADDR to a struct.  It turned
out to be quite difficult, because there's a deeply-embedded assumption
that CORE_ADDR is an offset in a unified byte address space.

So instead, I wrote a patch that takes GDB partway toward the struct
core_addr goal.  It insert a bunch of CORE_ADDR conversion macros that
create abstraction barriers between various CORE_ADDR generators and
consumers (user, hardware, target, object file).

My original motivation for the patch was to allow users to see and specify
real addresses without needing to know about the usual 0x1000000/0x2000000
offset and bit-shift conversions.  Compensating for those conversions
during assembly debugging is tedious and potentially confusing.

In the following text, I describe the patch largely from that perspective.
However, the patch is general enough to allow architectures to make their
own choices about how to translate user-visible addresses.

The Problem
===========

GDB handles Harvard architectures by mapping instruction and data spaces
onto a single byte address space.

For example, d10v-tdep.c performs the following mapping:
  data: 0x2000000 + addr
  insn: 0x1000000 + (addr << 2)

The mapping is user-visible, which I think is problematic because:

1. The user is inconvenienced by needing to know bit shifts and arbitrary
data/instruction offsets when specifying and viewing addresses.

2. The user won't necessarily know how GDB will modify registers.  $pc and
$sp are obvious candidates for modification, but other registers may have
multiple roles.  For example, a link register may hold an instruction
address immediately after a subroutine call, but it may hold data
addresses or even integer values after it's been saved on the stack.

3. Generally speaking, the purpose of GDB is to provide accurate
information about software and hardware, and GDB's address translation
diminishes that accuracy.  GDB should reveal, not obscure.

4. Expression evaluation breaks in any number of cases.  For example, if
GDB is stopped just after the mvfc instruction in a call to the following
D10V function with n=3:

        ;; prime(n): return the nth prime number for 1 <= n <= 3.
        .text
        .global prime
prime:
        ;; save link register
        st r13,@-sp

        ;; scale n by jump target size, add offset
        add r0,r0
        addi r0,1

        ;; calculate and jump to target pc
        mvfc r1,pc
        add r1,r0
        jmp r1

        ;; 1st prime number
        ldi r0,2
        bra .L1

        ;; 2nd prime number
        ldi r0,3
        bra .L1

        ;; 3rd prime number
        ldi r0,5
        nop
.L1:
        ;; restore link register and return
        ld r13,@sp+
        jmp r13

the following commands work incorrectly:

  (gdb) x/i $r13
  0x501d:       sub     r0, r0  ||      sub     r0, r0
  (gdb) x/i $r1 + $r0
  0x502c:       sub     r0, r0  ||      sub     r0, r0

GDB doesn't (and can't) know that $r13 and $r1 hold instruction addresses
and $r0 holds an instruction offset, so it doesn't apply the necessary
internal conversions before querying memory.  To compensate, the user
needs to enter the following:

  (gdb) x/i ($r13 << 2) + 0x1000000
  0x1014074 <main+24>:  mv      r1, r0  ->      mv      r0, r1
  (gdb) x/i ($r1 << 2) + 0x1000000 + ($r0 << 2)
  0x10140b0 <prime+40>: ldi.s   r0, 0x5 ||      nop     

Similar problems occur when dereferencing data addresses in registers.

A Solution
==========

Change GDB to treat user-visible addresses as real hardware addresses.

As has been discussed in other threads, this approach reveals the
ambiguity inherent in Harvard architectures.  For example, should "x/i 0"
disassemble the first word of the instruction space or the data space?

An obvious disambiguator is an address syntax extension that indicates the
address space.  In separate threads, Doug Evans proposed a "<space>:"
prefix and Per Bothner proposed a "@<space>" suffix.  E.g.:

  x/i insn:0

would disassemble instruction address 0 and

  x/i data:0

would disassemble data address 0.

I think that in the absence of the disambiguator, GDB should pick a
reasonable default, e.g. "x/i 0" would disassemble instruction address 0.
That worked well in the two (not-yet-public) ports that use this patch.

An Implementation
=================

Conceptually partition GDB into components that might have a unique
interpretation of CORE_ADDR, e.g.:

  user             addresses displayed to and received from the GDB user
  remote           addresses specified to remote target for memory I/O
  hardware         addresses written to/read from memory or registers
  object files     symbol addresses
  internal GDB     all other occurrences of CORE_ADDR

and apply appropriate conversions when crossing boundaries between those
components.  The patch does that using gdbarch macros with the following
nomenclature:

  ADDR_<direction>_<component>[_<space>]

  <direction>
     IN   moving to internal GDB from another component
     OUT  moving from internal GDB to another component

  <component>   
     REAL    user-visible and hardware addresses
     OBJ     symbol and entry-point addresses in object files
     GDB     internal GDB addresses
     SEC     offset in an object file section
     REMOTE  addresses specified to remote target for memory I/O

  <space>
     INSN  instruction space
     DATA  data space
     SEC   infer space from the struct sec argument
     TYPE  infer space from the struct type argument

For example, ADDR_IN_REAL_TYPE (CORE_ADDR addr, struct type *type) returns
the real address ADDR of a TYPE object converted to an internal gdb
address.  I've appended the current list of ADDR_* macros to this message.

[ADDR_IN_REAL_TYPE is identical to the existing POINTER_TO_ADDRESS; I
chose the alternative ADDR_* nomenclature because it results in shorter
names and reflects the hierarchical relationships between the macros.]

Architectures can use the ADDR_* macros to map multiple address spaces
into internal GDB CORE_ADDRs.  For convenience, I wrote a harvard.c module
that handles simple d10v-ish bit-shift and bit-offset mappings to and from
the current internal GDB unified byte address space.  The interface is:

extern void harvard_init (struct gdbarch *gdbarch,
                          CORE_ADDR gdb_data_off, int gdb_data_shift,
                          CORE_ADDR gdb_insn_off, int gdb_insn_shift,
                          CORE_ADDR obj_data_off, int obj_data_shift,
                          CORE_ADDR obj_insn_off, int obj_insn_shift,
                          CORE_ADDR remote_data_off, int remote_data_shift,
                          CORE_ADDR remote_insn_off, int remote_insn_shift);

I might split that into multiple calls to allow for future components.

I'll post the actual patch soon, and if people like the idea, I'll try
converting d10v-tdep.c to use it.

What do you think?

Nick

[gdbarch macros follow]

  ADDR_IN_REAL_DATA (CORE_ADDR addr)
    Return real data address ADDR converted to an internal gdb address.
  ADDR_IN_REAL_INSN (CORE_ADDR addr)
    Return real instruction address ADDR converted to an internal gdb
    address.
  ADDR_IN_REAL_SEC (CORE_ADDR addr, struct sec *sec)
    Return real address ADDR in SEC converted to an internal gdb address.
  ADDR_IN_REAL_TYPE (CORE_ADDR addr, struct type *type)
    Return real address ADDR of a TYPE object converted to an internal gdb
    address.
  ADDR_IN_OBJ_DATA (CORE_ADDR addr)
    Return object file data address ADDR converted to an internal gdb
    address.
  ADDR_IN_OBJ_INSN (CORE_ADDR addr)
    Return object file instruction address ADDR converted to an internal
    gdb address.
  ADDR_IN_OBJ_SEC (CORE_ADDR addr, struct sec *sec)
    Return object file address ADDR in SEC converted to an internal gdb
    address.
  ADDR_IN_OBJ (CORE_ADDR addr)
    Return object file address ADDR converted to an internal gdb address.
  ADDR_IN_OBJ_P ()
    Whether to apply ADDR_IN_OBJ* conversions.
  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.
  ADDR_OUT_REAL (CORE_ADDR addr)
    Return internal gdb address ADDR converted to a real address.
  ADDR_OUT_OBJ (CORE_ADDR addr)
    Return internal gdb address ADDR converted to an object file address.
  ADDR_OUT_SEC (CORE_ADDR addr)
    Return internal gdb address ADDR converted to an offset from the start
    of its section.
  ADDR_OUT_REMOTE (CORE_ADDR addr)
    Return internal gdb address ADDR converted to a remote address.
  ADDROFF_OUT_REAL (CORE_ADDR addr, CORE_ADDR offset)
    Return internal gdb address OFFSET from ADDR converted to a real
    address offset.

Re: Harvard proposal

[Per Bothner]

Nick Duffek <nsd@redhat.com> writes:

(Note: While I do question some of your concepts, there are a lot of
Gdb issues I'm unaware of.  So the questions are meant as real
questions, not rhetorical, and a request for a better explanation.)

>   <component>   
>      REAL    user-visible and hardware addresses

The word "REAL" is poorly chosen.  Is a "REAL" address an integer?
What about DEC-10-style "byte pointers"?  These were a triple (word
address, bit offset, bit count).  You might want to represent this
in gdb as a (36-bit) integer, but you probably don't want to print
them as a hex integer.  Thus "user-visible" and "hardware" are two
different things.

>      OBJ     symbol and entry-point addresses in object files

What is this?  File position from start of file?  (Why should anyone
except the object file reader care?)  Offset from start of section?
Isn't that just a relative address - i.e. an integer?

>      REMOTE  addresses specified to remote target for memory I/O

How is this different from REAL?

>   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.

>   ADDR_IN_REAL_DATA (CORE_ADDR addr)
>     Return real data address ADDR converted to an internal gdb address.
>   ADDR_IN_REAL_INSN (CORE_ADDR addr)
>     Return real instruction address ADDR converted to an internal gdb
>     address.

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).

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.

>   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.
An offset is just a plain integer (and perhaps a "unit" e.g.
bit/byte/word).

-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

Re: Harvard proposal

[Nick Duffek]

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

Re: Harvard proposal

[Andrew Cagney]

Nick Duffek wrote:

> The Problem
> ===========
> 
> GDB handles Harvard architectures by mapping instruction and data spaces
> onto a single byte address space.
> 
> For example, d10v-tdep.c performs the following mapping:
>   data: 0x2000000 + addr
>   insn: 0x1000000 + (addr << 2)
> 
> The mapping is user-visible, which I think is problematic because:

Just FYI, while the mapping is user visible it is also very entrenched. 
BFD, which doesn't handle segmentation either, uses that ``cannonical''
address form in its linker scripts and relocations.

	Andrew

Re: Harvard proposal

[Nick Duffek]

On 13-Feb-2001, Andrew Cagney wrote:

>Just FYI, while the mapping is user visible it is also very entrenched. 
>BFD, which doesn't handle segmentation either, uses that ``cannonical''
>address form in its linker scripts and relocations.

Yes, that's one reason why the ADDR_IN_OBJ* macros are needed.

Nick

Re: Harvard proposal

[Andrew Cagney]

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

Re: Harvard proposal

[Per Bothner]

Andrew Cagney <ac131313@cygnus.com> writes:

> 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).

To clarify: By "target address space" do you mean the combined address
spaces of all the targets put together, or the address space of any
single target?  In other words, should a CORE_ADDR would also provide
some way of identifying a specific sub-space (i.e. specific target)?
Or should sub-space identification (which subsumes process id and host
network address) be something *separate* from the CORE_ADDR?

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

Again to clarify:  We're talking *target* void*, represented as an
integer type in gdb, not a pointer type.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

Re: Harvard proposal

[Andrew Cagney]

Per Bothner wrote:
> 
> Andrew Cagney <ac131313@cygnus.com> writes:
> 
> > 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).
> 
> To clarify: By "target address space" do you mean the combined address
> spaces of all the targets put together, or the address space of any
> single target?  In other words, should a CORE_ADDR would also provide
> some way of identifying a specific sub-space (i.e. specific target)?
> Or should sub-space identification (which subsumes process id and host
> network address) be something *separate* from the CORE_ADDR?

In Chorus an ``actor''s address space; in UNIX, a single processes
memory space; on an SMP machine the address space visible to a single
CPU.

GDB currently doesn't understand the concept of multiple, separate
addresses spaces (as would be seen when debugging two separate UNIX
processes).

> > However, as with traditional C, I'd suggest following the convention of
> > CORE_ADDR (void*) for pointers and LONGEST (long) for offsets.
> 
> Again to clarify:  We're talking *target* void*, represented as an
> integer type in gdb, not a pointer type.

A C programmer would be accustomed to code using ``void*'' for a generic
address and ``long'' for a generic offset.  In a similar way, a GDB
developer would be accustomed to using CORE_ADDR when manipulating a
generic target address and (in theory) LONGEST when manipulating a
generic target offset.

	Andrew

Re: Harvard proposal

[Per Bothner]

Andrew Cagney <ac131313@cygnus.com> writes:

> In Chorus [a CORE_ADDR is] an ``actor''s address space; in UNIX, a
> single processes memory space; on an SMP machine the address space
> visible to a single CPU.

Which glosses over what happens when adta and instruction spaces
are separate.

> GDB currently doesn't understand the concept of multiple, separate
> addresses spaces (as would be seen when debugging two separate UNIX
> processes).

I know.  I thought that was what we trying to define, how Gdb *should*
handle the concept of multiple, separate addresses spaces.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

Re: Harvard proposal

[Andrew Cagney]

Per Bothner wrote:

(wonder what adta stands for)

> > GDB currently doesn't understand the concept of multiple, separate
> > addresses spaces (as would be seen when debugging two separate UNIX
> > processes).
> 
> I know.  I thought that was what we trying to define, how Gdb *should*
> handle the concept of multiple, separate addresses spaces.

Hmm, I think the problem is that ``separate address space'' is pretty
loosely defined.

Chorus (an OS) has a grouping thing called an actor.  An actor contains
a number of address spaces (or address translations) - text, data, io,
...  An actor also contains a number of threads.  Given that all threads
live within an actor they all interpret addresses according to that
actors address translations/spaces.  All the threads within an actor see
the world through the same set of eyes.

A Chorus systeme also contains multiple actors.  

I think people may be trying to solve what I would consider to be two
separate problems:

	1.	handling separate text, data and io
		spaces visible to the threads within
		a single actor.

	2.	handling multiple actors

		Or to put it another way, the possibility
		that two threads have two very different
		views of the world.

GDB can handle the debugging of an actor provided it only contains one
address space (unified text and data). It can kind of handle separate
text and data and totally fails to handle I/O.  GDB can't handle
multiple actors.

I think this discussion should should be focusing on ``1.''.

Just keep in mind things like ``space:address'' eventually becomming
context sensative (dependant on the current thread/actor) and the
possible need to expand things further to include
``actor::space:address'' say.

enjoy,
	Andrew