From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9469 invoked by alias); 29 Oct 2003 15:44:12 -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 9461 invoked from network); 29 Oct 2003 15:44:10 -0000 Received: from unknown (HELO zenia.home) (12.223.225.216) by sources.redhat.com with SMTP; 29 Oct 2003 15:44:10 -0000 Received: by zenia.home (Postfix, from userid 5433) id 724EE207AF; Wed, 29 Oct 2003 10:43:05 -0500 (EST) To: Kevin Buettner Cc: "Ken Dyck" , gdb@sources.redhat.com Subject: Re: FW: Targeting dual Harvard architectures References: <1031029082128.ZM5375@localhost.localdomain> From: Jim Blandy Date: Wed, 29 Oct 2003 15:44:00 -0000 In-Reply-To: <1031029082128.ZM5375@localhost.localdomain> 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/msg00322.txt.bz2 Kevin Buettner writes: > On Oct 29, 1:07am, Jim Blandy wrote: > > > - At the moment, make_type_with_address_space is doing two jobs --- > > it's handling both the address space stuff, and the non-standard > > pointer type stuff (at the moment, only s/390 'mode32' pointers). > > You'd probably need to split that into two distinct functions, and > > give them better names. Not sure here. > > It may also be possible to (re)implement the @code, @data mechanisms > using the address class methods. That might be the cleanest since it > would then be possible for an architecture to do whatever it wants > with regard to adding more address spaces. I.e. a dual Harvard > architecture could have @code, @data1, and @data2 or even more > suitable names which'd make more sense for that architecture. Hmm. Address spaces are mutually exclusive of each other --- but not of address classes. For example, there's no reason one couldn't have a '@mode32 @code char *'. But what combinations are permitted and which are nonsensical should be up to the target. Perhaps, instead of having gdbarch methods that turn a name into an int, we should have gdbarch methods that take a name, and the old int (initially zero), and return the new int. That is, let them modify the arch-specific flag set as needed, not just specify a new flag set. That way, Ken's architecture could set aside a bitfield for the spaces, and allocate other bits for whatever address classes the architecture supports. The gdbarch method itself would recognize that '@code @data1 @data2 char *' is a nonsensical type, and report the error, but would know that the (hypothetical) '@mode32 @code char *' is okay.