From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19625 invoked by alias); 19 Apr 2011 18:40:11 -0000 Received: (qmail 19610 invoked by uid 22791); 19 Apr 2011 18:40:09 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD 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; Tue, 19 Apr 2011 18:39:46 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p3JIdddg018088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Apr 2011 14:39:39 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p3JIdcmX001579; Tue, 19 Apr 2011 14:39:39 -0400 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p3JIdcxY020185; Tue, 19 Apr 2011 14:39:38 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id BEAE237930B; Tue, 19 Apr 2011 12:39:37 -0600 (MDT) From: Tom Tromey To: Pedro Alves Cc: gdb-patches@sourceware.org, Sergio Durigan Junior Subject: Re: [PATCH 3/6] Modify internalvar mechanism References: <201104121224.31901.pedro@codesourcery.com> <201104191852.58106.pedro@codesourcery.com> Date: Tue, 19 Apr 2011 18:40:00 -0000 In-Reply-To: <201104191852.58106.pedro@codesourcery.com> (Pedro Alves's message of "Tue, 19 Apr 2011 18:52:57 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00335.txt.bz2 >>>>> "Pedro" == Pedro Alves writes: Pedro> Do I understand correctly that this still creates Pedro> a regular trap tracepoint at the probe location? Pedro> A fast tracepoint ("ftrace") at that spec would Pedro> create a fast tracepoint at the probe's location, and Pedro> things would magically work, because $_probe_argN is just Pedro> sugar for collecting memory and registers, right? I believe it should all work, but I did not think to try fast tracepoints. I don't know whether Sergio did. Yes, the probe arguments are just a wrapper around some kind of assembly-level operand. These are known statically to gdb; the operands are encoded as strings in the appropriate section. A good part of the main patch is devoted to parsing these. It might be nice if we had a way to print the operand strings. This isn't always useful, but maybe we could add some optional flag to "info probe". Or, maybe just another flag to readelf. Pedro> I noticed that patch 4 does some changes to Pedro> start_tracing to tweak the probes' semaphores, if any. Pedro> What are these semaphores? How do other stap tools Pedro> handle them? I ask because that bends a bit the definition Pedro> of "trace" being a regular tracepoint at a given Pedro> location, so I'd like to understand it. A probe can optionally have an associated "semaphore". A semaphore in the sdt.h sense is just a global variable (of type unsigned short) which can be used to gate the probe. Typically these are only generated by code using the dtrace compatibility wrappers. Without a semaphore a probe may look like: STAB_PROBE (provider, name, arg); But with a semaphore it would more typically be written (though I think in practice there may be macros expanding to the semaphore name): if (provider_name_semaphore) STAB_PROBE (provider, name, arg); Aside from providing some source compatibility with dtrace probes, this can also be used in a situation where computing the probe arguments is expensive. In Fedora 15, at least Python takes this approach. But, OTOH, libgcc and glibc do not. The only other tool I know of that deals with these probe points is SystemTap. It treats the semaphore as a counter. I don't know the specifics, but basically it is incremented by stap at "attach" and decremented at "detach". We made gdb work the same way, for compatibility. (I have not done it but I believe it is possible to use stap and gdb to probe the same process at the same time.) So, since setting the semaphore is necessary to make the probe even trigger, it seemed to make sense to have gdb set it, and to leave it set during the trace experiment. One reason we decided to make `probe:' linespecs special with regard to semaphores is because it makes it clear that the user has asked for some additional behavioral change on top of the breakpoint. (We could alternatively have made `break *0xaddress' magically work at a probe point, the way we did for probe arguments...) Tom