Hey James,
This is all working as intended.
As you know, a DTrace probe is identified by the four-tuple of provider,
module, function, and name. Two locations for a USDT probe will differ only
in the function components. This is true of is-enabled probes as well as
normal probes.
There are two things we could do to make the case you describe less confusing.
One is to indicate that a given probe is exclusively an is-enabled site. That
seems like a questionable practice, but I could imagine an implementation
where that arrangement might be the most logical.
The second thing we could do is have a mode for dtrace -l in which we only
listed the components of the probe that were relevant. For example, it's
unusual for a user to enable only _some_ SDT or USDT probes so in this mode
those would be coalesced into a single listing.
What do you think?
Adam
On Wed, Aug 13, 2008 at 03:03:44PM -0700, James McIlree wrote:
>
> I have a user that was adding some rather expensive probes to library
> code.
> Their code ended up factoring in such a way that the main line code
> had IS_ENABLED()
> tests guarding calls to another function that did the real work of
> argument construction
> and calling the actual dtrace probe.
>
> Somewhat unusually, when run, dtrace reports multiple probes instead
> of just one.
>
> I boiled the test case down into these two functions:
>
> void functionA(int value) {
> if (SIMPLE_MYSIMPLEPROBE_ENABLED()) {
> printf("No probe called, but mySimpleProbe() is enabled\n");
> }
> }
>
> void functionB(int value) {
> if (SIMPLE_MYSIMPLEPROBE_ENABLED()) {
> SIMPLE_MYSIMPLEPROBE(value);
> }
> }
>
> On both Solaris and OS X, when an app containing these functions is
> run, dtrace
> reports:
>
> /home/ovrskeek# dtrace -l -n "Simple*:::"
> ID PROVIDER MODULE FUNCTION
> NAME
> 512 Simple15950 simple functionB
> mySimpleProbe
> 513 Simple15950 simple functionA
> mySimpleProbe
>
> It seems to me like we're missing something here. If I have both an
> is-enabled
> and a regular probe in the same function, dtrace reports finding one
> probe. If I have
> either separately, dtrace reports finding one probe. Somehow, I'm
> either losing a probe
> in the "both" case, or gaining one in the IS_ENABLED() only case.
>
> This is a bit confusing to consumers as well, consider the case of
>
> /home/ovrskeek# dtrace -l -n "Simple*:::"
> ID PROVIDER MODULE FUNCTION
> NAME
> 512 Simple15950 simple functionB
> mySimpleProbe
> 513 Simple15950 simple functionA
> mySimpleProbe
> /home/ovrskeek# dtrace -n "Simple*::functionA:"
> dtrace: description 'Simple*::functionA:' matched 1 probe
>
> DTrace told me I had a probe in functionA, I *know* functionA is
> being called, but
> no output?
>
> Of course, if we eliminate all IS_ENABLED probes, then they cannot be
> used stand-alone.
>
> Darned if we do, darned if we don't :-).
>
> I'm thinking perhaps we need a visual clue that a given probe is is-
> enabled only?
>
> Is there a better way to convey to consumers the type & number of
> probes at a given point?
> It seem like there are usage scenarios where you need information that
> isn't available (today)
> without inspecting the source.
>
> James M
>
> _______________________________________________
> dtrace-discuss mailing list
> [email protected]
--
Adam Leventhal, Fishworks http://blogs.sun.com/ahl
_______________________________________________
dtrace-discuss mailing list
[email protected]
