On Oct 26, 2007, at 3:27 PM, Adam Leventhal wrote:
> On Fri, Oct 26, 2007 at 04:51:44PM -0500, Robert Lor wrote:
>> We're not using 'dtrace -h' now, so I'm not following how the
>> 'dtrace -G..."
>> step can be removed. Maybe I'm missing something!
>
> Ah. I thought that Apple might have added <sys/dtrace.h> and kept
> the output
> of 'dtrace -h' compatible with the macros. In fact, they've done
> something
> sort of clever. The generated header file contains a slightly
> different
> reference to the private symbol names; Apple them must have modified
> their
> compiler or linker to do the work of 'dtrace -G'.
>
> I say sort of clever because the probes themselves contain the
> stability
> information whereas we use 'dtrace -G' to transmit the stability
> into the
> final DOF object. I've included an example here for the probe
> foo*:::bar.
> Note that is-enabled probes don't have the stability magic so I'm
> not sure
> how things would work if only is-enabled probes were used.
>
> To all USDT developers: you should definitely start using 'dtrace -h'
> To Apple: you should make dtrace -G a no-op so that said developers
> don't
> have to change their Makefiles
>
> Adam
It looks like you've worked out most of the details already, but just
for
clarification :-).
OS X doesn't support the older DTRACE_PROBE style macros, only
the newer (and much safer!) typechecked generated header files.
We did actually look at trying to support a compatibility mode with -G
being a no-op, but that turned out to be something of a slippery slope.
The harder I pulled on that thread, the more corner cases I found where
it fell over. As Steve mentioned, we know its an issue, and I filed:
<rdar://problem/5566030> Emulate dtrace -G for compatibility
Your insight about the is-enabled probes is on target, if you attempt
to only use is-enabled probes, and never reference the actual dtrace
probe,
you'll get link time errors.
James M
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
