From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25046 invoked by alias); 27 Dec 2010 08:20:50 -0000 Received: (qmail 25026 invoked by uid 22791); 27 Dec 2010 08:20:46 -0000 X-SWARE-Spam-Status: No, hits=-0.8 required=5.0 tests=AWL,BAYES_50,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-wy0-f169.google.com (HELO mail-wy0-f169.google.com) (74.125.82.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 27 Dec 2010 08:20:37 +0000 Received: by wyj26 with SMTP id 26so8635635wyj.0 for ; Mon, 27 Dec 2010 00:20:34 -0800 (PST) Received: by 10.216.82.68 with SMTP id n46mr2209467wee.90.1293438034403; Mon, 27 Dec 2010 00:20:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.182.206 with HTTP; Mon, 27 Dec 2010 00:20:14 -0800 (PST) In-Reply-To: References: <201012191039.oBJAdNBN010655@glazunov.sibelius.xs4all.nl> <20101221084248.1c922955@mesquite.lan> <20101221230428.43315eea@mesquite.lan> <20101222083648.7321acbc@mesquite.lan> From: Hui Zhu Date: Mon, 27 Dec 2010 13:20:00 -0000 Message-ID: Subject: Re: [RFA/RFC] mips tracepoint: fix Bug 12013 To: Kevin Buettner , Joel Brobecker Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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/msg00468.txt.bz2 On Thu, Dec 23, 2010 at 10:57, Hui Zhu wrote: > On Wed, Dec 22, 2010 at 23:36, Kevin Buettner wrote: >> 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. =A0I will do it. >> >> Please look at Pedro's reply. =A0He 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 =A0Hui Zhu =A0 >>> >>> =A0 =A0 =A0 * mips-tedp.c (mips_register_name): Add comments. >>> >>> --- >>> =A0mips-tdep.c | =A0 =A07 ++++++- >>> =A01 file changed, 6 insertions(+), 1 deletion(-) >>> >>> --- a/mips-tdep.c >>> +++ b/mips-tdep.c >>> @@ -454,7 +454,12 @@ mips_register_name (struct gdbarch *gdba >>> =A0 =A0enum mips_abi abi =3D mips_abi (gdbarch); >>> >>> =A0 =A0/* Map [gdbarch_num_regs .. 2*gdbarch_num_regs) onto the raw reg= isters, >>> - =A0 =A0 but then don't make the raw register names visible. =A0*/ >>> + =A0 =A0 but then don't make the raw register names visible. >>> + =A0 =A0 Because It is possible to debug a 64-bit device using a 32-bi= t programming >>> + =A0 =A0 model. =A0In such instances, the raw registers are configured= to be >>> + =A0 =A0 64-bits wide, while the pseudo registers are configured to be= 32-bits >>> + =A0 =A0 wide. =A0The registers that the user sees - the pseudo regist= ers - match >>> + =A0 =A0 the user's expectations given the programming model being use= d. =A0*/ >> >> Could you revise the comment to read as follows? >> >> =A0 =A0/* Map [gdbarch_num_regs .. 2*gdbarch_num_regs) onto the raw regi= sters, >> =A0 =A0 =A0 but do not make the raw register names visible. =A0This (upp= er) >> =A0 =A0 =A0 range of user visible register numbers are the >> =A0 =A0 =A0 pseudo-registers. >> >> =A0 =A0 =A0 This approach was adopted accomodate the following scenario: >> =A0 =A0 =A0 It is possible to debug a 64-bit device using a 32-bit >> =A0 =A0 =A0 programming model. =A0In such instances, the raw registers a= re >> =A0 =A0 =A0 configured to be 64-bits wide, while the pseudo registers are >> =A0 =A0 =A0 configured to be 32-bits wide. =A0The reigsters that the user >> =A0 =A0 =A0 sees - the pseudo registers - match the users expectations >> =A0 =A0 =A0 given the programming model being used. =A0*/ >> >> Please allow several days for others to tweak my suggested wording. =A0If >> there are no further comments on the above wording, feel free to commit >> it. Checked in. Joel, do you think this patch can check in to 7.2.1. Thanks, Hui >> >> Thanks, >> >> Kevin >> > > OK. =A0 Thanks Kevin. > > Best, > Hui > > > 2010-12-23 =A0Kevin Buettner =A0 > =A0 =A0 =A0 =A0 =A0 =A0Hui Zhu =A0 > > =A0 =A0 =A0 =A0* mips-tedp.c (mips_register_name): Add comments. > > --- > =A0mips-tdep.c | =A0 11 ++++++++++- > =A01 file changed, 10 insertions(+), 1 deletion(-) > > --- a/mips-tdep.c > +++ b/mips-tdep.c > @@ -454,7 +454,16 @@ mips_register_name (struct gdbarch *gdba > =A0 enum mips_abi abi =3D mips_abi (gdbarch); > > =A0 /* Map [gdbarch_num_regs .. 2*gdbarch_num_regs) onto the raw register= s, > - =A0 =A0 but then don't make the raw register names visible. =A0*/ > + =A0 =A0 but then don't make the raw register names visible. =A0This (up= per) > + =A0 =A0 range of user visible register numbers are the pseudo-registers. > + > + =A0 =A0 This approach was adopted accommodate the following scenario: > + =A0 =A0 It is possible to debug a 64-bit device using a 32-bit > + =A0 =A0 programming model. =A0In such instances, the raw registers are > + =A0 =A0 configured to be 64-bits wide, while the pseudo registers are > + =A0 =A0 configured to be 32-bits wide. =A0The registers that the user > + =A0 =A0 sees - the pseudo registers - match the users expectations > + =A0 =A0 given the programming model being used. =A0*/ > =A0 int rawnum =3D regno % gdbarch_num_regs (gdbarch); > =A0 if (regno < gdbarch_num_regs (gdbarch)) > =A0 =A0 return ""; >