From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23348 invoked by alias); 22 Dec 2010 15:36:56 -0000 Received: (qmail 22943 invoked by uid 22791); 22 Dec 2010 15:36:55 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 22 Dec 2010 15:36:50 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id oBMFamK8020885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 22 Dec 2010 10:36:49 -0500 Received: from mesquite.lan ([10.3.113.8]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id oBMFamrh030879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 22 Dec 2010 10:36:48 -0500 Date: Wed, 22 Dec 2010 16:20:00 -0000 From: Kevin Buettner To: gdb-patches@sourceware.org Subject: Re: [RFA/RFC] mips tracepoint: fix Bug 12013 Message-ID: <20101222083648.7321acbc@mesquite.lan> In-Reply-To: References: <201012191039.oBJAdNBN010655@glazunov.sibelius.xs4all.nl> <20101221084248.1c922955@mesquite.lan> <20101221230428.43315eea@mesquite.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: 2010-12/txt/msg00402.txt.bz2 On Wed, 22 Dec 2010 15:12:22 +0800 Hui Zhu wrote: > > You might consider implementing a new gdbarch method which provides a > > mapping from pseudo register numbers to raw register numbers. __The > > trace machinery could use such a mapping to find the corresponding raw > > register(s) when presented with a pseudo register. __I can think of > > several potential pitfalls with this approach, but I think the idea is > > worth exploring. > > Thanks Kevin. I will do it. Please look at Pedro's reply. He has outlined a better approach. > And I make a patch to add some comments from your mail to mips_register_name. > Wish it can help other people. > > Please help me review it. Okay, see below... > 2010-12-22 Hui Zhu > > * mips-tedp.c (mips_register_name): Add comments. > > --- > mips-tdep.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > --- a/mips-tdep.c > +++ b/mips-tdep.c > @@ -454,7 +454,12 @@ mips_register_name (struct gdbarch *gdba > enum mips_abi abi = mips_abi (gdbarch); > > /* Map [gdbarch_num_regs .. 2*gdbarch_num_regs) onto the raw registers, > - but then don't make the raw register names visible. */ > + but then don't make the raw register names visible. > + Because It is possible to debug a 64-bit device using a 32-bit programming > + model. In such instances, the raw registers are configured to be > + 64-bits wide, while the pseudo registers are configured to be 32-bits > + wide. The registers that the user sees - the pseudo registers - match > + the user's expectations given the programming model being used. */ Could you revise the comment to read as follows? /* Map [gdbarch_num_regs .. 2*gdbarch_num_regs) onto the raw registers, but do not make the raw register names visible. This (upper) range of user visible register numbers are the pseudo-registers. This approach was adopted accomodate the following scenario: It is possible to debug a 64-bit device using a 32-bit programming model. In such instances, the raw registers are configured to be 64-bits wide, while the pseudo registers are configured to be 32-bits wide. The reigsters that the user sees - the pseudo registers - match the users expectations given the programming model being used. */ Please allow several days for others to tweak my suggested wording. If there are no further comments on the above wording, feel free to commit it. Thanks, Kevin