From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3895 invoked by alias); 29 Oct 2003 17:19:03 -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 3888 invoked from network); 29 Oct 2003 17:19:01 -0000 Received: from unknown (HELO zenia.home) (12.223.225.216) by sources.redhat.com with SMTP; 29 Oct 2003 17:19:01 -0000 Received: by zenia.home (Postfix, from userid 5433) id A2EDC207AF; Wed, 29 Oct 2003 12:17:58 -0500 (EST) To: Andrew Cagney Cc: Ken Dyck , gdb@sources.redhat.com Subject: Re: FW: Targeting dual Harvard architectures References: <3F9EA019.2030003@redhat.com> From: Jim Blandy Date: Wed, 29 Oct 2003 17:19:00 -0000 In-Reply-To: <3F9EA019.2030003@redhat.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-10/txt/msg00325.txt.bz2 Andrew Cagney writes: > > "Ken Dyck" writes: > > > >> 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. > > Yes --- with the understanding that it's restricted to just distinct > > code and data spaces at the moment --- you can say: > > x/i (@code char *) 0x1234 > > x/i (@data char *) 0x1234 > > and it'll do the right thing, if you define the ADDRESS_TO_POINTER > > and > > POINTER_TO_ADDRESS methods appropriately. > > (Hey, this isn't in the GDB manual anywhere!) > > But you've actually got a case where this needs to be extended to > > support an arbitrary set of architecture-defined spaces, which the > > current code does not support. If I recall correctly, this was > > discussed when the current @code and @data support went in, but it was > > left as a future extension, since we didn't know of any architectures > > that actually wanted it. Now we do. > > Yep. The original patch was integrated with the understanding that > the hard-wired "code" and "data" namespaces would eventually be > replaced with a generic address space naming mechanism (ex, 86 and > @code @data @stack and @io). > > For a broad idea of how it can be implemented, look at reggroups (and > maint print register-groups). It lets an architecture define an > arbitrary number of register groupings. Yeah, reggroups might be a nice model to imitate here. They were very straightforward to add to an unreleased port I was working on recently --- not fussy at all. The only thing I worry about is that, while reggroups exist mostly for GDB's internal benefit (save/restore) and for user interface (general/vector), the address spaces are a real part of the architecture, so they have to model whatever freakyness the hardware designers can come up with. I was originally thinking, "Address spaces are mutually exclusive; there's no way that attaching two address space qualifiers to a type could be meaningful. That's gotta be an error." But when I think about all the weird architectures out there, I'm really inclined to just provide the expression syntax and space in 'struct type' to let the architecture do *whatever it wants* with the address<->pointer relationship, and have the architecture-independent code keep its hands clean. If there is some order to all this, let it come from the architecture, rather than presuming it in the arch-independent code.