From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5808 invoked by alias); 29 Sep 2014 13:53:53 -0000 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 Received: (qmail 5795 invoked by uid 89); 29 Sep 2014 13:53:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_20,LIKELY_SPAM_BODY,RP_MATCHES_RCVD,SPF_PASS,UNPARSEABLE_RELAY autolearn=no version=3.3.2 X-HELO: userp1040.oracle.com Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 29 Sep 2014 13:53:52 +0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s8TDrhj6012179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 29 Sep 2014 13:53:43 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8TDrerT001736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Sep 2014 13:53:42 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8TDre7O001719; Mon, 29 Sep 2014 13:53:40 GMT Received: from termi.oracle.com (/10.175.164.118) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 29 Sep 2014 06:53:38 -0700 From: jose.marchesi@oracle.com (Jose E. Marchesi) To: Eli Zaretskii Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 8/9] Documentation for DTrace USDT probes. References: <1411724905-31234-1-git-send-email-jose.marchesi@oracle.com> <1411724905-31234-9-git-send-email-jose.marchesi@oracle.com> <83oau2tt9w.fsf@gnu.org> <87wq8m7m69.fsf@oracle.com> <83bnpymtwl.fsf@gnu.org> Date: Mon, 29 Sep 2014 13:53:00 -0000 In-Reply-To: <83bnpymtwl.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 29 Sep 2014 16:35:22 +0300") Message-ID: <87bnpy7cl1.fsf@oracle.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00833.txt.bz2 > > +Some @code{SystemTap} probes have an associated semaphore variable; > > +for instance, this happens automatically if you defined your probe > > +using a DTrace-style @file{.d} file. If your probe has a semaphore, > > +@value{GDBN} will automatically enable it when you specify a > > +breakpoint using the @samp{-probe-stap} notation. But, if you put a > > +breakpoint at a probe's location by some other method (e.g., > > +@code{break file:line}), then @value{GDBN} will not automatically set > > +the semaphore. @code{DTrace} probes do not support the notion of > > +semaphores. > > The last sentence confused me: you first explain something that seems > to imply semaphores are part of DTrace probes, but then say that they > don't support semaphores. What am I missing? > > The paragraph starts explaining that SystemTap probes may have > associated semaphore variables, followed by a short description on how > gdb handles these variables. That was part of the original > documentation on SystemTap probes. > > I just added the last sentence to note that DTrace probes do not support > semaphore variables at all. > > I don't see where the confusion is? The confusion starts with the fact that "DTrace" is mentioned twice, the first time in the context of discussing semaphores. Aaah, that mention to the "DTrace-like" file. Yes, I agree, it can be confusing now that DTrace probes are also supported. How about the following rewrite: Some @code{SystemTap} probes have an associated semaphore variable. If your probe has a semaphore, @value{GDBN} will automatically enable it when you specify a breakpoint using the @samp{-probe-stap} notation. But, if you put a breakpoint at a probe's location by some other method (e.g., @code{break file:line}), then @value{GDBN} will not automatically set the semaphore. @code{DTrace} probes do not support semaphore variables associated with them. I think that is indeed better than the current wording. Thanks. > > +probe being handled. Some @code{DTrace} probes can be enabled or > > +disabled, but @code{SystemTap} probes do not support these notions. > > Which "notions"? If you want to say they cannot be disabled, please > say so explicitly. > > No, I want to say that SystemTap probes do not even support the notion > of being enabled or disabled. That is not quite the same than saying > that SystemTap probes cannot be disabled: for example some DTrace probes > cannot be disabled because they are always enabled. Sorry, I don't see the difference between "cannot be disabled" and "don't support the notion of being enabled or disabled". A trap that cannot be disabled is by definition always enabled, right? So from the user point of view, saying they cannot be disabled says it all, right? Well... right, from the user perspective SystemTap probes are always enabled... Ok, I will follow your suggestion and just mention that SystemTap probes cannot be disabled.