From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29253 invoked by alias); 19 Apr 2011 17:53:13 -0000 Received: (qmail 29233 invoked by uid 22791); 19 Apr 2011 17:53:12 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 19 Apr 2011 17:52:58 +0000 Received: (qmail 31536 invoked from network); 19 Apr 2011 17:52:57 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 19 Apr 2011 17:52:57 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [PATCH 3/6] Modify internalvar mechanism Date: Tue, 19 Apr 2011 17:53:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.35-28-generic; KDE/4.6.2; x86_64; ; ) Cc: Sergio Durigan Junior , Tom Tromey References: <201104121224.31901.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201104191852.58106.pedro@codesourcery.com> 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: 2011-04/txt/msg00333.txt.bz2 On Tuesday 12 April 2011 23:33:05, Sergio Durigan Junior wrote: > Pedro Alves writes: > > > On Monday 04 April 2011 04:08:34, Sergio Durigan Junior wrote: > >> Hi, > >> > >> This patch modifies the mechanism of internalvar. It basically adds > >> more manipulation functions to them (`compile_to_ax' and `destroy'), and > >> updates the definitions and pointers of existing internalvars. > > > > Can you explain this? Why would you want to compile an internal var > > to AX, for example? > > A SystemTap probe can have up to 10 arguments. In our original plan, > the idea is that the user should be able to collect those arguments > using the tracepoint mechanism. Since we already have the necessary > code to evaluate an argument (which is treated as an internal varibale > inside GDB), we thought it would be easier to extend this code in order > to compile it to AX. > > You could do something like: > > (gdb) trace probe:test > .. > (gdb) actions > .. > > collect $_probe_arg0 > > end > .. Do I understand correctly that this still creates a regular trap tracepoint at the probe location? A fast tracepoint ("ftrace") at that spec would create a fast tracepoint at the probe's location, and things would magically work, because $_probe_argN is just sugar for collecting memory and registers, right? I noticed that patch 4 does some changes to start_tracing to tweak the probes' semaphores, if any. What are these semaphores? How do other stap tools handle them? I ask because that bends a bit the definition of "trace" being a regular tracepoint at a given location, so I'd like to understand it. > In order to collect the probe's first argument, and so on. I see. Sounds like a good approach. (I'm reading patch 4 piecemeal, but it's taking a bit to grok it all). -- Pedro Alves