From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24512 invoked by alias); 29 Oct 2003 16:59:30 -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 24501 invoked from network); 29 Oct 2003 16:59:28 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 29 Oct 2003 16:59:28 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 428612B89; Tue, 28 Oct 2003 11:58:01 -0500 (EST) Message-ID: <3F9EA019.2030003@redhat.com> Date: Wed, 29 Oct 2003 16:59:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Blandy Cc: Ken Dyck , gdb@sources.redhat.com Subject: Re: FW: Targeting dual Harvard architectures References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-10/txt/msg00324.txt.bz2 > "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. Andrew