From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13195 invoked by alias); 22 Dec 2010 06:04:38 -0000 Received: (qmail 13181 invoked by uid 22791); 22 Dec 2010 06:04:36 -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 06:04:31 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id oBM64Toc021122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 22 Dec 2010 01:04:29 -0500 Received: from mesquite.lan ([10.3.113.8]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id oBM64T8k011470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 22 Dec 2010 01:04:29 -0500 Date: Wed, 22 Dec 2010 06:04:00 -0000 From: Kevin Buettner To: gdb-patches@sourceware.org Subject: Re: [RFA/RFC] mips tracepoint: fix Bug 12013 Message-ID: <20101221230428.43315eea@mesquite.lan> In-Reply-To: References: <201012191039.oBJAdNBN010655@glazunov.sibelius.xs4all.nl> <20101221084248.1c922955@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/msg00389.txt.bz2 On Tue, 21 Dec 2010 23:58:29 +0800 Hui Zhu wrote: > Thanks. Do 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. In 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. 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. Kevin