From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19025 invoked by alias); 27 Oct 2003 13:13:24 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 19018 invoked from network); 27 Oct 2003 13:13:24 -0000 Received: from unknown (HELO mic.dspfactory.com) (216.16.237.2) by sources.redhat.com with SMTP; 27 Oct 2003 13:13:24 -0000 Subject: FW: Targeting dual Harvard architectures Date: Mon, 27 Oct 2003 13:13:00 -0000 MIME-Version: 1.0 To: gdb@sources.redhat.com Cc: From: "Ken Dyck" Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-SW-Source: 2003-10/txt/msg00284.txt.bz2 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