From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2344 invoked by alias); 18 Dec 2007 15:15:12 -0000 Received: (qmail 2306 invoked by uid 22791); 18 Dec 2007 15:15:10 -0000 X-Spam-Check-By: sourceware.org Received: from dmz.mips-uk.com (HELO dmz.mips-uk.com) (194.74.144.194) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 18 Dec 2007 15:15:04 +0000 Received: from internal-mx1 ([192.168.192.240] helo=ukservices1.mips.com) by dmz.mips-uk.com with esmtp (Exim 3.35 #1 (Debian)) id 1J4e9t-00012d-00; Tue, 18 Dec 2007 15:15:01 +0000 Received: from ukcvpn53.mips-uk.com ([192.168.193.53]) by ukservices1.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1J4e9p-0001qN-00; Tue, 18 Dec 2007 15:14:57 +0000 Message-ID: <4767E3F0.6090903@mips.com> Date: Tue, 18 Dec 2007 16:06:00 -0000 From: Nigel Stephens User-Agent: IceDove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: drow@false.org CC: gdb-patches@sourceware.org, Chris Dearman , "Maciej W. Rozycki" Subject: Re: MIPS: Handle the DSP registers References: <20071218004304.GA29420@caradoc.them.org> <4767CE18.3050307@mips.com> <20071218135623.GA6919@caradoc.them.org> In-Reply-To: <20071218135623.GA6919@caradoc.them.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MIPS-Technologies-UK-MailScanner: Found to be clean X-MIPS-Technologies-UK-MailScanner-From: nigel@mips.com X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-12/txt/msg00288.txt.bz2 Daniel Jacobowitz wrote: > On Tue, Dec 18, 2007 at 01:41:44PM +0000, Nigel Stephens wrote: > >> Sounds like this mechanism could rapidly get unwieldy if there were many >> disjoint, optional register sets supported by an architecture -- would >> you need a different description for each possible permutation? For >> example with a bare-iron target you might want to omit the >> floating-point register descriptions for CPUs which don't have a h/w >> FPU, so then we've got Base, Base+FPU, Base+DSP, Base+FPU+DSP. Then >> double again for 32-bit vs 64-bit, and so on. Or have I missed something. >> > > You have, but it's a very small thing. > > The hand-written descriptions in the GDB source code serve three > purposes. They are used for gdbserver (which could be made smarter); > they are used for GDB (but only to eliminate the build dependency on > expat); and they are used as canonical examples for stub writers. > > There's at least two ways we could support a large set of combinations > in GDB. One is to require expat, provide XML files at the feature > level, and generate the top level target description using strcat > (one of CodeSourcery's stubs does it this way). The other is to > adjust the precompiling process, which currently generates a callable > C function per target description, to generate functions at the > feature level and call those from within GDB. That's a bit nicer. > Yes, FWIW my vote would be for function per feature. > Since so far we only support MIPS with an attached FPU (due to change > somewhere in MTI's GDB patch collection, I think?) there's only four > descriptions, so no one's bothered to do that flexibility yet. But > the framework is there when we need it :-) > > gdbserver is not very bright; its register set is selected entirely at > compile time and the C parts know a bit about the layout of the XML > parts. Eventually, it's going to grow multiple description support > just like GDB, I think. I just haven't needed it yet. > > OK, thanks. Nigel