From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19827 invoked by alias); 21 Dec 2010 14:58:50 -0000 Received: (qmail 19815 invoked by uid 22791); 21 Dec 2010 14:58:50 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,TW_CP,TW_EG,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO glazunov.sibelius.xs4all.nl) (83.163.83.176) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 21 Dec 2010 14:58:42 +0000 Received: from glazunov.sibelius.xs4all.nl (kettenis@localhost [127.0.0.1]) by glazunov.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id oBLEwb5j011526; Tue, 21 Dec 2010 15:58:37 +0100 (CET) Received: (from kettenis@localhost) by glazunov.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id oBLEwZHd013682; Tue, 21 Dec 2010 15:58:36 +0100 (CET) Date: Tue, 21 Dec 2010 14:58:00 -0000 Message-Id: <201012211458.oBLEwZHd013682@glazunov.sibelius.xs4all.nl> From: Mark Kettenis To: teawater@gmail.com CC: gdb-patches@sourceware.org In-reply-to: (message from Hui Zhu on Tue, 21 Dec 2010 22:45:15 +0800) Subject: Re: [RFA/RFC] mips tracepoint: fix Bug 12013 References: <201012191039.oBJAdNBN010655@glazunov.sibelius.xs4all.nl> 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/msg00375.txt.bz2 > From: Hui Zhu > Date: Tue, 21 Dec 2010 22:45:15 +0800 > > Did not get any reason. ? > Checked in. I told you this is wrong. You'll have to fix this in a different way. I'm not familliar with the tracepoint stuff, so I can't really help you with that. Please back this out immediately. > On Sun, Dec 19, 2010 at 20:15, Hui Zhu wrote: > > On Sun, Dec 19, 2010 at 18:39, Mark Kettenis wrote: > >>> From: Hui Zhu > >>> Date: Sun, 19 Dec 2010 16:35:59 +0800 > >>> > >>> http://sourceware.org/bugzilla/show_bug.cgi?id=12013 > >>> > >>> 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.  What 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.  So 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?  I 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 *buf) > > { > >  gdb_assert (regnum >= 0); > >  gdb_assert (regnum < regcache->descr->nr_cooked_registers); > >  if (regnum < regcache->descr->nr_raw_registers) > >    regcache_raw_read (regcache, regnum, buf); > >  else if (regcache->readonly_p > >           && regnum < regcache->descr->nr_cooked_registers > >           && regcache->register_valid_p[regnum]) > >    /* Read-only register cache, perhaps the cooked value was cached?  */ > >    memcpy (buf, register_buffer (regcache, regnum), > >            regcache->descr->sizeof_register[regnum]); > >  else > >    gdbarch_pseudo_register_read (regcache->descr->gdbarch, regcache, > >                                  regnum, buf); > > } > > > > For now, even if gdb doesn't how to handle pseudo, it put it to > > gdbarch.  I need add a new interface to gdbarch to handle it if we > > really need. > > > > Thanks, > > Hui > > > >> > >>> 2010-12-19  Hui Zhu   > >>> > >>>       * mips-tdep.c (mips_register_name): Remove the check. > >>>       (mips_print_registers_info): Remove the gdb_assert. > >>> > >> > > > >