This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

FW: Targeting dual Harvard architectures


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]