Harvard Addressing

[Matt Kern <matt dot kern at undue dot org>]

As I mentioned in a previous email, I am in the process of porting GDB
to a Harvard machine.  GDB requires us to flatten our two address spaces
into a single, unified address space;  the code address space spans 0x0
- 0x00ffffff, while the data address space spans 0x01000000 -
0x0100ffff.

Currently, however the toolchain does not merge the address spaces;  the
code address space spans 0x0 - 0x00ffffff, while the data address space
spans 0x0 - 0x0000ffff.  This means that you can have a code symbol,
foo, _and_ a data symbol, bar, both with VMA 0x2c0.

This leads to a problem.  If I run a program up to a breakpoint in GDB,
and then "print bar" where bar is a global int, the address that GDB
attempts to access, 0x2c0, is derived directly from bar's symbol value.
I need the address to be 0x010002c0 if GDB is to work correctly.

There don't appear to be any out-of-the-box architecture hooks that
would let me resolve this issue easily.  I've experimented with fixing
up symbol values, both at the value level (e.g. in read_var_value()) and
when reading debug information (e.g. in dwarf2read.c).  In both cases
the type information necessary for distinguishing code/data addresses is
available.  I suspect fixing up values will leave major internal
problems.  Fixing up the symbols with the debug information on the other
hand looks to be a significant job;  there doesn't appear to be a single
point in dwarf2read.c that would accomodate such a hook.

Should I proceed down the route of fixing up symbols?  If so, should I
fix them up using the DWARF2 information that we have available?

Alternatively, should I back out these changes and look to mod the
toolchain to produce data addresses in the 0x01000000 - 0x0100ffff
range?

Matt

-- 
Matt Kern
http://www.undue.org/