From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30042 invoked by alias); 7 Nov 2011 17:20:56 -0000 Received: (qmail 30026 invoked by uid 22791); 7 Nov 2011 17:20:55 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 07 Nov 2011 17:20:41 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1RNSsC-0001ms-PR from pedro_alves@mentor.com ; Mon, 07 Nov 2011 09:20:40 -0800 Received: from scottsdale.localnet ([172.16.63.104]) by EU1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Nov 2011 17:20:38 +0000 From: Pedro Alves To: gdb@sourceware.org Subject: Re: Tracepoints and Timestamps Date: Mon, 07 Nov 2011 17:20:00 -0000 User-Agent: KMail/1.13.6 (Linux/2.6.38-12-generic; KDE/4.7.2; x86_64; ; ) Cc: Stan Shebs References: <4EB80415.7010304@earthlink.net> In-Reply-To: <4EB80415.7010304@earthlink.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201111071720.31400.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2011-11/txt/msg00052.txt.bz2 On Monday 07 November 2011 16:15:17, Stan Shebs wrote: > On 11/7/11 6:53 AM, Abhishek Karoliya wrote: > > Hi Hui, > > > > Thanks for the pointer ... However after going through the > > gdbserver source code, I realise that there is no tracepoint support > > for linux-ppc. So now I have a even bigger problem on my hand. > > > > Does anyone know if I can ppc tracepoint support being actively > > developed and if I can lay my hands on this experimental code. > > > > The tracepoint support in GDBserver is pretty generic, and if you don't > need fast tracepoints, there's not really anything that is arch-specific. > > I would suggest enabling target_supports_tracepoints for ppc and letting > us know how it goes. If it "just works", then we could change the > target_supports_tracepoints test to make it unconditional. We can't. The backend needs to be able to step over breakpoints so it can step over tracepoints without gdb involvement. Which means, it either needs to support hardware single-step (ppc does), or, it'll need to know how to software single-step. No gdbserver port can do the latter. And it should ideally switch to using gdbserver side breakpoints (z0/Z0 packets, the insert_point/remove_point hooks), so breakpoints and tracepoints can coexist. linux-ppc-low.c should install the supports_tracepoints hook like linux-x86-low.c does: static int x86_supports_tracepoints (void) { return 1; } and insert_point/remote_point hooks, like x86_insert_point/x86_remove_point. The Z0 insert/remove code support would ideally be moved to the gdbserver core side, controlled by a new "use software breakpoints" hook added to gdbserver's target vector, so that bit of code could be reused. -- Pedro Alves