From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26702 invoked by alias); 22 Dec 2010 07:12:50 -0000 Received: (qmail 26690 invoked by uid 22791); 22 Dec 2010 07:12:49 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,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; Wed, 22 Dec 2010 07:12:44 +0000 Received: by wyj26 with SMTP id 26so4921144wyj.0 for ; Tue, 21 Dec 2010 23:12:42 -0800 (PST) Received: by 10.216.183.3 with SMTP id p3mr7008588wem.105.1293001962178; Tue, 21 Dec 2010 23:12:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.182.206 with HTTP; Tue, 21 Dec 2010 23:12:22 -0800 (PST) In-Reply-To: <20101221230428.43315eea@mesquite.lan> References: <201012191039.oBJAdNBN010655@glazunov.sibelius.xs4all.nl> <20101221084248.1c922955@mesquite.lan> <20101221230428.43315eea@mesquite.lan> From: Hui Zhu Date: Wed, 22 Dec 2010 07:12:00 -0000 Message-ID: Subject: Re: [RFA/RFC] mips tracepoint: fix Bug 12013 To: Kevin Buettner 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/msg00390.txt.bz2 On Wed, Dec 22, 2010 at 14:04, Kevin Buettner wrote: > On Tue, 21 Dec 2010 23:58:29 +0800 > Hui Zhu wrote: > >> Thanks. =A0Do you think I can add a special name for these raw registers >> then other part can use this raw register if need. > > I have a hunch that such an approach will result in an assertion > failure in mips_print_registers_info() when a raw register name is > used to attempt to print a register. > > The other problem with such an approach is that it again exposes the > raw registers to the user. =A0In this case, instead of using the name > "sp", the user would instead have to use "raw-sp" (or some such). > This is not completely horrible, but it's certainly not as nice as > allowing the user to continue referring to standard nomenclature when > using the trace machinery. > > You might consider implementing a new gdbarch method which provides a > mapping from pseudo register numbers to raw register numbers. =A0The > trace machinery could use such a mapping to find the corresponding raw > register(s) when presented with a pseudo register. =A0I can think of > several potential pitfalls with this approach, but I think the idea is > worth exploring. > > Kevin > Thanks Kevin. I will do it. And I make a patch to add some comments from your mail to mips_register_nam= e. Wish it can help other people. Please help me review it. Thanks, Hui 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 =3D 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 progra= mming + 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. */ int rawnum =3D regno % gdbarch_num_regs (gdbarch); if (regno < gdbarch_num_regs (gdbarch)) return "";