This is the mail archive of the
mailing list for the GDB project.
- From: Matt Kern <matt dot kern at undue dot org>
- To: GDB <gdb at sourceware dot org>
- Date: Tue, 5 Jun 2007 14:52:10 +0100
- Subject: Harvard Addressing
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 -
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