From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10839 invoked by alias); 29 Oct 2003 06:08:18 -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 10794 invoked from network); 29 Oct 2003 06:08:11 -0000 Received: from unknown (HELO zenia.home) (12.223.225.216) by sources.redhat.com with SMTP; 29 Oct 2003 06:08:11 -0000 Received: by zenia.home (Postfix, from userid 5433) id AB288207AF; Wed, 29 Oct 2003 01:07:11 -0500 (EST) To: "Ken Dyck" Cc: gdb@sources.redhat.com Subject: Re: FW: Targeting dual Harvard architectures References: From: Jim Blandy Date: Wed, 29 Oct 2003 06:08:00 -0000 In-Reply-To: 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/msg00317.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. > 2. What changes would be necessary? Well, at the moment, TYPE_FLAG_CODE_SPACE and TYPE_FLAG_DATA space are just two distinct flags that could be attached to a type. Similarly, "@code" and "@data" are hard-coded in gdbtypes.c. What I think we want to do is put the vocabulary of address space flags entirely under the control of target-specific code, via gdbarch methods. - The type flags would be broken out into their own field of 'struct type' (not 'struct main_type'). It could just be an int; core GDB would always call gdbarch methods to operate on it, so its interpretation would be completely at the convenience of the arch-specific code. If you wanted to be very pure, you could use a void * instead of an int. - There'd be a gdbarch method for turning an address space name into one of these ints, for parsing, and another for turning an int into a name, for printing. - 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. - You'd need to fix up the existing targets that use the type flags to use the new ints. It looks like just avr-tdep.c and d10v-tdep.c. - If it turns out that all the targets that are using these address spaces end up using similar code and data structures for it, you'll want to look at factoring things out into support functions, so targets with trivial needs ("I just have N address spaces named X, Y, Z, ...") can get what they need with trivial tdep code. > 3. How much effort would be involved in making such modifications? Most of the time would go into figuring out how things work now. The actual changes wouldn't be too bad, since it doesn't seem like there's too much code that mucks about with this stuff; just bits here and there. So how good you are at finding your way through unfamiliar code would be the dominating factor, I'd guess.