Re: harvard architectures - the d10v

[Per Bothner <per at bothner dot com>]

David Taylor <taylor@cygnus.com> writes:

> Currently, GDB and to a lesser extent the binutils/gas/ld toolsuite,
> deal with Harvard Architectures by adding extra bits to allow them to
> treat the system as having a unified address space.

The problem of multiple address spaces is a more general problem:

* We want to be able to use a single debugger to debug a distributed
program running as mutiple processes.

* Likewise, with the programs running on separate hardware with
different architectures.

* We want to be able to debug normal machine code as well as
an interpreter ("virtual machine code").

* We want to debug programs that have separate data and instruction
spaces.

The cleanest solution would be to define CORE_ADDR as a struct:

struct core_addr {
  struct address_space *target;
  uint64_t addr;
};

typedef struct core_addr CORE_ADDR;

struct address_space {
  pointer to table of functions that take a core_addr;
  ... address-space-specific data, such as process id ...;
};

#define ADDR_ADDRESS_SPACE(ADDR) ((ADDR)->target)
#define ADDR_VALUE(ADDR) ((ADDR)->target)

This would be the Right Thing, but it might be a lot of work
to convert Gdb.  Perhaps not - I don't know.  An interim step
might be using certain high-order bits of an integer as an
index into a table of address spaces:

typedef unit64_t CORE_ADDR;

struct addr_space normal_addr_space = { ... };
struct addr_space *(addr_space_table[256]) = {
  normal_addr_space,
  normal_addr_space,
  ...
};

#define ADDR_ADDRESS_SPACE(ADDR) addr_space_table[(ADDR) >> 56]
#define ADDR_VALUE(ADDR) (ADDR_ADDRESS_SPACE(ADDR)->addr_value(ADDR))

Something like the above can probably be implemented very easily,
without breaking any "normal" architectures.  You can then relatively
cleanly implement support for multiple address spaces in this framework
- just plud in new addr_spaces in the addr_space_table.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/