From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31421 invoked by alias); 27 Feb 2008 18:33:59 -0000 Received: (qmail 31413 invoked by uid 22791); 27 Feb 2008 18:33:59 -0000 X-Spam-Check-By: sourceware.org Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 27 Feb 2008 18:33:42 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id 75D163BFBE; Wed, 27 Feb 2008 10:33:40 -0800 (PST) Subject: Re: Tracepoints functionality for local targets From: Michael Snyder To: Lokesh Gupta Cc: gdb@sourceware.org In-Reply-To: <21b011a40802270008u4efb67av598dce53a828913f@mail.gmail.com> References: <21b011a40802260027r596c2c0bt96339538b8e5cc92@mail.gmail.com> <1204051129.19253.305.camel@localhost.localdomain> <21b011a40802270008u4efb67av598dce53a828913f@mail.gmail.com> Content-Type: text/plain Date: Wed, 27 Feb 2008 22:00:00 -0000 Message-Id: <1204137220.19253.415.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-7.fc7) Content-Transfer-Encoding: 7bit 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-02/txt/msg00233.txt.bz2 On Wed, 2008-02-27 at 09:08 +0100, Lokesh Gupta wrote: > Hello, > > Can't we take the following approach to this issue: > > - Treat tracepoints as 'silent' breakpoints such that when the user > sets tracepoints actually a breakpoint is inserted with a special > property called as 'trace-silent' > - During execution, when this breakpoint is hit, the usual GDB flow of > handling the breakpoint comes into picture, GDB gets control, it > collects all required data from the current frame ($regs,$args,$locals > as requested by user for this tracepoint), and then silently continues > the execution because it can identify it as a special breakpoint with > the property of 'trace-silent' This would definitely be one possible implementation. By the way, the tracepoint framework was designed to be largely implementation-independent, so that to a large extent it should be able to work with any of a number of different implementations. What you suggest would have the advantage of being pretty general (should work with native/remote/sim/whatever), but it has one big disadvantage -- as soon as gdb becomes involved with the tracepoint data collection, you lose the advantage of speed. Part of the goal of tracepoints is to be as un-intrusive as possible -- get in and get out without interfering with the timing of the target system any more than necessary. If you're willing to compromise that goal, then you can do things as you describe. There's also no reason we can't have multiple tracepoint implementations in place at the same time, so long as we have a way of selecting between them. Eg. turn off the general-but-slow method if you have available a target-specific-but-fast method.