From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8946 invoked by alias); 21 Dec 2010 14:45:44 -0000 Received: (qmail 8933 invoked by uid 22791); 21 Dec 2010 14:45:42 -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,TW_CP,TW_EG,T_TO_NO_BRKTS_FREEMAIL 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; Tue, 21 Dec 2010 14:45:38 +0000 Received: by wyj26 with SMTP id 26so4155343wyj.0 for ; Tue, 21 Dec 2010 06:45:35 -0800 (PST) Received: by 10.216.183.3 with SMTP id p3mr6061941wem.105.1292942735655; Tue, 21 Dec 2010 06:45:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.182.206 with HTTP; Tue, 21 Dec 2010 06:45:15 -0800 (PST) In-Reply-To: References: <201012191039.oBJAdNBN010655@glazunov.sibelius.xs4all.nl> From: Hui Zhu Date: Tue, 21 Dec 2010 14:45:00 -0000 Message-ID: Subject: Re: [RFA/RFC] mips tracepoint: fix Bug 12013 To: gdb-patches@sourceware.org Cc: Mark Kettenis 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/msg00374.txt.bz2 Did not get any reason. Checked in. Thanks, Hui On Sun, Dec 19, 2010 at 20:15, Hui Zhu wrote: > On Sun, Dec 19, 2010 at 18:39, Mark Kettenis wr= ote: >>> From: Hui Zhu >>> Date: Sun, 19 Dec 2010 16:35:59 +0800 >>> >>> http://sourceware.org/bugzilla/show_bug.cgi?id=3D12013 >>> >>> This bug make mips tracepoint cannot trace the backtrace. >>> >>> This patch to fix this issue with a directly way just remove the >>> decline of access to the raw register names. >>> >>> If you think it's not OK. =A0What about add a new interface to gdbarch >>> to access to the raw register names. >> >> It is a common trick to return an empty register name for a (raw) >> register to hide the register from the user. =A0So I don't think this >> diff is ok, since the goal obviously is to hide the raw registers in >> mips in favour of the pseudo registers. > > Could you tell me what this hide for? =A0I didn't find who get some > advantage form this part? > >> >> I'd say the proper way forward is to teach the trace code to handle >> pseudo registers. > > void > regcache_cooked_read (struct regcache *regcache, int regnum, gdb_byte *bu= f) > { > =A0gdb_assert (regnum >=3D 0); > =A0gdb_assert (regnum < regcache->descr->nr_cooked_registers); > =A0if (regnum < regcache->descr->nr_raw_registers) > =A0 =A0regcache_raw_read (regcache, regnum, buf); > =A0else if (regcache->readonly_p > =A0 =A0 =A0 =A0 =A0 && regnum < regcache->descr->nr_cooked_registers > =A0 =A0 =A0 =A0 =A0 && regcache->register_valid_p[regnum]) > =A0 =A0/* Read-only register cache, perhaps the cooked value was cached? = =A0*/ > =A0 =A0memcpy (buf, register_buffer (regcache, regnum), > =A0 =A0 =A0 =A0 =A0 =A0regcache->descr->sizeof_register[regnum]); > =A0else > =A0 =A0gdbarch_pseudo_register_read (regcache->descr->gdbarch, regcache, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0regnum= , buf); > } > > For now, even if gdb doesn't how to handle pseudo, it put it to > gdbarch. =A0I need add a new interface to gdbarch to handle it if we > really need. > > Thanks, > Hui > >> >>> 2010-12-19 =A0Hui Zhu =A0 >>> >>> =A0 =A0 =A0 * mips-tdep.c (mips_register_name): Remove the check. >>> =A0 =A0 =A0 (mips_print_registers_info): Remove the gdb_assert. >>> >> >