From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31578 invoked by alias); 12 Jun 2007 14:50:07 -0000 Received: (qmail 31567 invoked by uid 22791); 12 Jun 2007 14:50:06 -0000 X-Spam-Check-By: sourceware.org Received: from pollux.ds.pg.gda.pl (HELO pollux.ds.pg.gda.pl) (153.19.208.7) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 12 Jun 2007 14:50:03 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 0EB5BE1CE4; Tue, 12 Jun 2007 16:49:50 +0200 (CEST) Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux.ds.pg.gda.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wB6ONsV38dcm; Tue, 12 Jun 2007 16:49:49 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id B1FBAE1CC0; Tue, 12 Jun 2007 16:49:49 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l5CEo1lV025459; Tue, 12 Jun 2007 16:50:01 +0200 Date: Tue, 12 Jun 2007 14:50:00 -0000 From: "Maciej W. Rozycki" To: Daniel Jacobowitz cc: Ulrich Weigand , gdb-patches@sourceware.org Subject: Re: [rfc][4/13] Eliminate read_register: read_register in deprecated_mips_set_processor_regs_hack In-Reply-To: <20070612142003.GG7815@caradoc.them.org> Message-ID: References: <200706072058.l57KwV3u019800@d12av02.megacenter.de.ibm.com> <20070612142003.GG7815@caradoc.them.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Status: Clean 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/msg00173.txt.bz2 On Tue, 12 Jun 2007, Daniel Jacobowitz wrote: > > 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. I will. > 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. Worse yet -- the approach that we have taken is generic. We can handle arbitrary MIPS32/MIPS64 processors as conforming to the current revisions of the base architecture specs and the application-specific extensions (ASEs) by decoding feature bits defined in cp0 config registers -- there four config registers defined so far; additional registers may need to be read for variable length register subsets (e.g. watch and performance counter registers). These in turn may differ between members of the same processor family based on configuration of a given system which might be hardwired and/or configured from the bootstrap bits. Further changes may be obtained by fiddling with some processor-specific configuration bits, for example in some implementations the MMU may be switched between the TLB and the fixed mode and this affects some cp0 registers. There are only two or three variations that care of specific processor IDs from PRId -- all the rest is generic using PRId to determine whether a chip is a MIPS architecture or a legacy implementation only. Using PRId as a selector here would be a maintenance nightmare -- there are too many of them. > 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. Well, it's actually in mips-tdep.c, so it should work for any MIPS target. > Of course you can also make any remote MIPS targets respond with XML > tags :-) I guess this is unfeasible -- there are too many possibilites which are neither fixed nor easy to predict as you can see from the above. Unless the XML tags provide means for subsetting the architecture. Please note that to make the matter more exciting the subsets do overlap. I shall see how the change fits into gdb in its current state and submit the proposal as soon as feasible. Maciej