From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21600 invoked by alias); 18 Dec 2007 13:56:34 -0000 Received: (qmail 21587 invoked by uid 22791); 18 Dec 2007 13:56:32 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 18 Dec 2007 13:56:25 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 5C26498151; Tue, 18 Dec 2007 13:56:24 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 436F398129; Tue, 18 Dec 2007 13:56:24 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.68) (envelope-from ) id 1J4cvn-0001t8-Fw; Tue, 18 Dec 2007 08:56:23 -0500 Date: Tue, 18 Dec 2007 15:15:00 -0000 From: Daniel Jacobowitz To: Nigel Stephens Cc: gdb-patches@sourceware.org, Chris Dearman , "Maciej W. Rozycki" Subject: Re: MIPS: Handle the DSP registers Message-ID: <20071218135623.GA6919@caradoc.them.org> Mail-Followup-To: Nigel Stephens , gdb-patches@sourceware.org, Chris Dearman , "Maciej W. Rozycki" References: <20071218004304.GA29420@caradoc.them.org> <4767CE18.3050307@mips.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4767CE18.3050307@mips.com> User-Agent: Mutt/1.5.17 (2007-12-11) 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/msg00287.txt.bz2 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. 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. -- Daniel Jacobowitz CodeSourcery