From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26860 invoked by alias); 6 Jan 2010 00:55:22 -0000 Received: (qmail 26852 invoked by uid 22791); 6 Jan 2010 00:55:21 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from elasmtp-dupuy.atl.sa.earthlink.net (HELO elasmtp-dupuy.atl.sa.earthlink.net) (209.86.89.62) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 06 Jan 2010 00:55:14 +0000 Received: from [70.170.59.51] (helo=macbook-2.local) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NSKAq-0001DE-F7; Tue, 05 Jan 2010 19:54:56 -0500 Message-ID: <4B43DF5F.9060007@earthlink.net> Date: Wed, 06 Jan 2010 00:55:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tromey@redhat.com CC: Stan Shebs , gdb-patches@sourceware.org Subject: Re: [PATCH] Fast tracepoints References: <4B42A628.5060302@codesourcery.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: ae6f8838ff913eba0cc1426638a40ef67e972de0d01da94028d954b1fea50cbfbcb703ecfacb36c2350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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-01/txt/msg00093.txt.bz2 Tom Tromey wrote: >>>>>> "Stan" == Stan Shebs writes: >>>>>> > > Stan> This patch adds "fast" tracepoints to GDB. > > Neat. > > Stan> Most of the interesting trickery is on the target side - but don't > Stan> despair, Pedro has upcoming patches for a free version using gdbserver > Stan> and a special library. > > I wonder whether this could somehow work with systemtap probe points. > One of our other projects is to do "static tracepoints" that originate outside GDB, and one of the side effects of the upcoming disconnected tracing patch is that it introduces the idea of keeping the tracepoint definition in the target. So it seems like a useful convergence to have a tool-independent notion of a probe/tracepoint that can be used in different contexts. > It seems like it would be nicer for the user if the _at method returned > a reason, so that it could be printed as "May not have a fast > tracepoint: ... : reason". > Yeah, I considered it. It seemed like a localization mess to be constructing strings from strings, plus I find it distasteful to have the callee decide to allocate space in a way that compels the caller to think about what to do with it. But as you observe, predicates doing printouts isn't great either. Stan