FW: Targeting dual Harvard architectures

["Ken Dyck" <Ken.Dyck@dspfactory.com>]

My employer is considering targeting gdb (and binutils) to their DSP
chip. Like many DSPs, ours is a dual Harvard architecture with three
separate memory spaces: one for instructions and two for data. There's a
fourth, if you count non-volatile EEPROM.

I understand from a thread that Andrew Cagney started in February of
2001 (http://sources.redhat.com/ml/gdb/2001-02/msg00082.html) that
although gdb has been targeted to architectures with multiple memory
spaces, like d10v and avr, by mapping each memory space into a region
within a larger address space, the results leave much to be desired.
Nick Duffek summarized the problem when he proposed a partial solution
(http://sources.redhat.com/ml/gdb/2001-02/msg00107.html).

Per Bothner proposed defining CORE_ADDR as a struct as a first
step(http://sources.redhat.com/ml/gdb/2001-02/msg00086.html). Andrew's
response to Per's proposal
(http://sources.redhat.com/ml/gdb/2001-02/msg00091.html) gives me the
impression that his idea has been discussed in gdb circles before. Does
it still have merit?

Some time before AVR support was introduced, the CODE_SPACE and
DATA_SPACE macros were added to support Harvard architectures
(http://sources.redhat.com/ml/gdb/2002-02/msg00145.html). I suppose
another macro could be added to support dual Harvard architectures. Say,
DATA_SPACE2. It seems like a kludge to me, though. Comments?

Has there been any more discussion about targeting gdb to Harvard
architectures in the gdb mailing list or elsewhere since then? I haven't
been able to find anything that seems relevant beyond what I have
referenced above. Any suggestions?

The questions that I seek to answer are these:

1. Is it possible to modify gdb to support architectures with multiple
memory spaces in a "user friendly" way (where "user friendly" is
something like what David Taylor described in
http://sources.redhat.com/ml/gdb/2001-02/msg00090.html)? So far my
impression is yes.

2. What changes would be necessary?

3. How much effort would be involved in making such modifications?

Any pointers or comments would be welcome.

Ken