Re: [PATCH 8/9] Documentation for DTrace USDT probes.

Eli Zaretskii
2014-09-29T13:35:42Z

> 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?