From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5339 invoked by alias); 18 Dec 2007 13:42:00 -0000 Received: (qmail 5326 invoked by uid 22791); 18 Dec 2007 13:41:59 -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 13:41:55 +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 1J4chj-0001fW-00; Tue, 18 Dec 2007 13:41:51 +0000 Received: from ukcvpn53.mips-uk.com ([192.168.193.53]) by ukservices1.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1J4chc-0004ih-00; Tue, 18 Dec 2007 13:41:45 +0000 Message-ID: <4767CE18.3050307@mips.com> Date: Tue, 18 Dec 2007 13:56: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> In-Reply-To: <20071218004304.GA29420@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/msg00286.txt.bz2 Daniel Jacobowitz wrote: > > >> Index: binutils-quilt/src/gdb/features/mips-linux.xml >> =================================================================== >> --- binutils-quilt.orig/src/gdb/features/mips-linux.xml 2007-12-07 15:08:21.000000000 +0000 >> +++ binutils-quilt/src/gdb/features/mips-linux.xml 2007-12-07 15:13:02.000000000 +0000 >> @@ -11,6 +11,7 @@ >> >> >> >> + >> > > And a corrolary of that is that we'll have two mips-linux > descriptions, with and without the DSP registers. > 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. Nigel