From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31179 invoked by alias); 29 Sep 2014 13:35:42 -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 31168 invoked by uid 89); 29 Sep 2014 13:35:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_50,LIKELY_SPAM_BODY,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout20.012.net.il Received: from mtaout20.012.net.il (HELO mtaout20.012.net.il) (80.179.55.166) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 29 Sep 2014 13:35:35 +0000 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NCO00M0008KBE00@a-mtaout20.012.net.il> for gdb-patches@sourceware.org; Mon, 29 Sep 2014 16:35:31 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NCO00LNE0F7VS40@a-mtaout20.012.net.il>; Mon, 29 Sep 2014 16:35:31 +0300 (IDT) Date: Mon, 29 Sep 2014 13:35:00 -0000 From: Eli Zaretskii Subject: Re: [PATCH 8/9] Documentation for DTrace USDT probes. In-reply-to: <87wq8m7m69.fsf@oracle.com> To: jose.marchesi@oracle.com (Jose E. Marchesi) Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83bnpymtwl.fsf@gnu.org> 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> X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00832.txt.bz2 > From: jose.marchesi@oracle.com (Jose E. Marchesi) > Cc: gdb-patches@sourceware.org > Date: Mon, 29 Sep 2014 12:31:26 +0200 > > > > +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. 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. > > +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?