From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8466 invoked by alias); 12 Jun 2007 14:19:54 -0000 Received: (qmail 8457 invoked by uid 22791); 12 Jun 2007 14:19:54 -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, 12 Jun 2007 14:19:51 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id A2300982DE; Tue, 12 Jun 2007 14:19:49 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 4F308982DC; Tue, 12 Jun 2007 14:19:49 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.67) (envelope-from ) id 1Hy7E3-00045V-HB; Tue, 12 Jun 2007 10:20:03 -0400 Date: Tue, 12 Jun 2007 14:19:00 -0000 From: Daniel Jacobowitz To: "Maciej W. Rozycki" Cc: Ulrich Weigand , gdb-patches@sourceware.org Subject: Re: [rfc][4/13] Eliminate read_register: read_register in deprecated_mips_set_processor_regs_hack Message-ID: <20070612142003.GG7815@caradoc.them.org> Mail-Followup-To: "Maciej W. Rozycki" , Ulrich Weigand , gdb-patches@sourceware.org References: <200706072058.l57KwV3u019800@d12av02.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.15 (2007-04-09) 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-06/txt/msg00163.txt.bz2 On Fri, Jun 08, 2007 at 01:27:56PM +0100, Maciej W. Rozycki wrote: > > (Not sure if this is still required, or if it could be replaced by > > the new XML register mechanism ...) > > Well, if the latter provides similar means. I have extensive changes > pending for deprecated_mips_set_processor_regs_hack() and this access > definitely has to stay. In the new GDB scheme for such things, a processor with different register names should be a different gdbarch. The XML descriptions are just one way of specifying a new architecture variant and which variant to use - there are other ways, too. I would recommend a look at remote_read_description, which provides another way that is closer to what you need here. It's not a perfect fit, though. What deprecated_mips_set_processor_regs_hack could be doing is waiting until the point where we know the architecture well enough to find the PRID register contents, and then selecting a variant of the architecture based on that PRID value. But we do not know the register layout yet at the point of target_read_description; we don't know which registers are provided or how big they are. I don't have an easy answer for this. Simplest would be to keep it local to remote-mips.c (as it currently is), but change how it works; move it from common_open to a new remote_mips_read_description, fetch the PRID without going through GDB's register cache at all, and then create an appropriate target description which specifies the processor based on the PRID. It would be nicer if we could make it work for remote.c too though. Of course you can also make any remote MIPS targets respond with XML tags :-) -- Daniel Jacobowitz CodeSourcery