From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8998 invoked by alias); 29 Sep 2014 10:26:46 -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 8969 invoked by uid 89); 29 Sep 2014 10:26:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,LIKELY_SPAM_BODY,RP_MATCHES_RCVD,SPF_PASS,UNPARSEABLE_RELAY autolearn=no version=3.3.2 X-HELO: aserp1040.oracle.com Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com) (141.146.126.69) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 29 Sep 2014 10:26:43 +0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s8TAQYjQ022672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 29 Sep 2014 10:26:35 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8TAQYjU004741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Sep 2014 10:26:34 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8TAQYdZ001881; Mon, 29 Sep 2014 10:26:34 GMT Received: from termi.oracle.com (/10.175.164.118) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 29 Sep 2014 03:26:33 -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> Date: Mon, 29 Sep 2014 10:26:00 -0000 In-Reply-To: <83oau2tt9w.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 26 Sep 2014 16:18:03 +0300") Message-ID: <87wq8m7m69.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/msg00826.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? > +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.