From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22552 invoked by alias); 6 Jan 2010 09:39:48 -0000 Received: (qmail 22539 invoked by uid 22791); 6 Jan 2010 09:39:47 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 06 Jan 2010 09:39:43 +0000 Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o069dXsi009499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Jan 2010 04:39:33 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o069dUP1030181; Wed, 6 Jan 2010 04:39:31 -0500 Subject: Re: [PATCH] Fast tracepoints From: Mark Wielaard To: Stan Shebs Cc: tromey@redhat.com, Stan Shebs , gdb-patches@sourceware.org, systemtap@sourceware.org In-Reply-To: <4B43DF5F.9060007@earthlink.net> References: <4B42A628.5060302@codesourcery.com> <4B43DF5F.9060007@earthlink.net> Content-Type: text/plain; charset="UTF-8" Date: Wed, 06 Jan 2010 09:39:00 -0000 Message-ID: <1262770770.5133.41.camel@hermans.wildebeest.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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/msg00107.txt.bz2 Hi Stan, On Tue, 2010-01-05 at 16:54 -0800, Stan Shebs wrote: > 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. If you have a proposal please do CC systemtap@sourceware.org (I added it to the CC of this email already). Currently the way systemtap user space static probe points are handled is by having dtrace compatible source code markers in the application. We choose that representation in the source files to maximize reuse of static user space tracepoints across application/os domains. See also: http://sourceware.org/systemtap/wiki/AddingUserSpaceProbingToApps If we could reuse the definitions in sys/sdt.h as the canonical way of adding static tracepoints to an application usable from multiple debuggers/profilers/tracers that would be wonderful. The markers are currently stored in a special .probes elf section inside the application or shared library. I don't believe that format is documented yet (partly because there are still some experiments going on with adding different representations), but we probably should document it formally if we would like gdb to reuse it. Cheers, Mark