From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9569 invoked by alias); 3 Nov 2008 09:12:33 -0000 Received: (qmail 9510 invoked by uid 22791); 3 Nov 2008 09:12:32 -0000 X-Spam-Check-By: sourceware.org Received: from mail.idnet.net.uk (HELO mail.idnet.net.uk) (212.69.36.63) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 03 Nov 2008 09:11:34 +0000 Received: from [91.135.5.64] by mail.idnet.net.uk (GMS 15.01.3664/NU3963.00.7ca42f0c) with ESMTP id oolpfnba for gdb@sourceware.org; Mon, 3 Nov 2008 09:11:26 +0000 Subject: Re: Tracepoint enhancements From: Jeremy Bennett Reply-To: jeremy.bennett@embecosm.com To: gdb@sourceware.org In-Reply-To: <490B630F.8010008@codesourcery.com> References: <490B630F.8010008@codesourcery.com> Content-Type: text/plain Date: Mon, 03 Nov 2008 09:12:00 -0000 Message-Id: <1225703489.3694.69.camel@thomas> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) Content-Transfer-Encoding: 7bit X-AuthenticatedSender: jeremy.bennett.embecosm.com@idnet.net.uk 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: 2008-11/txt/msg00009.txt.bz2 On Fri, 2008-10-31 at 12:57 -0700, Stan Shebs wrote: > There is some interest in pumping up GDB's tracepoint capabilities, in > particular to make it more suitable for cross-debugging a target with > serious performance constraints. While a lot of the detail is centered > around making a faster stub and other low-level tweaks, we are going to > do MI for tracing finally, plus it's an opportunity to review the > existing trace commands and consider what interface changes are > desirable. In particular, we will want to think about how tracing should > interoperate with non-stop debugging and multi-process. > > So the first question that comes to my mind is: how many people are > actually using the trace commands right now? If they're not being much > used, then we have more flexibility about making user-visible changes. I've been working on the OpenRISC 1000, which has hardware trace support. No one has yet complained that I dropped trace functionality from GDB 6.8 for OpenRISC, so I guess it's not currently in use by that user community. > One possible change to consider is to merge tracepoint setting into > breakpoint setting. Among other benefits would be a single numbering > scheme for breakpoints and tracepoints, plus we will be able to share > some machinery and make things more consistent. I'd strongly encourage a uniform reference scheme. Not necessarily just numbers - something richer may be needed in complex environments. This should work for ANY target covering breakpoints, watchpoints, catchpoints, tracepoints etc. This ties in with your work on multiprocess/multiprogram support. A debugging target might be a complex SoC with multiple heterogenous processor cores together with peripherals having substantial state and processing power. Eventually GDB should be able to handle all of this consistently. This will require a standard way of addressing ANY part of such a target - not just within one processor - and turning it into a unique reference for GDB. For example I could specify a watchpoint on internal state of a peripheral, asking for execution to stop (on some or all threads/processes/processors/peripherals) if that internal state changed. At some stage a general way of linking the reference to a complex specification will be needed. I am not sure that "condition" and "break ... if" are sufficient. They certainly will need to reference multiple threads and target functional units. > A bigger change would be to introduce a general notion of execution > history, which could subsume fork checkpoints and trace snapshots, maybe > tie into some versions of reverse debugging as well. Which also requires a way of specifying what execution you are talking about. A uniform way of addressing potentially hundreds of thousands of threads of control individually and in arbitrary groupings. Some of this is a long way in the future, but I hope it provides a context for thinking about changes to GDB today. > What else should we be thinking about doing? > > (There are of course all kinds of implementation-level changes to make, > but at the moment I'm focussed on the user experience.) Keep up the good work :-) HTH, Jeremy -- Tel: +44 (1202) 416955 Cell: +44 (7970) 676050 SkypeID: jeremybennett Email: jeremy.bennett@embecosm.com Web: www.embecosm.com