Re: Probes in shared libs going missing

[Stan Cox <scox at redhat dot com>]

On 07/01/2010 02:00 AM, Steve Fink wrote:

> But I still don't understand why. If the command to build libmozjs.so
> includes mozjs-dtrace.o, then why doesn't it get linked in?

dtrace's 'dtrace -G' builds a binary containing the probe definitions and goes 
through .o files and replaces probe points with noops.  I'm not familiar with 
the dtrace implementation details, but it does not appear to me that 
mozjs-dtrace.o is linked into libmozjs.so.  Although the stap dtrace 
compatibility script appears to do the same thing, it actually is only 
defining a semaphore value corresponding to each probe in -s foo.d.  It does 
nothing with the *.o files;  the stap sdt.h itself defines a nop corresponding 
to each probe point.

> What does it mean for a static variable to be generated by dtrace -G?

The semaphore variables are external static variables.  The probe points in 
the routines that make up libmozjs.so reference these external static 
variables; but since mozjs-dtrace.o is not part of the libmozjs.so link; they 
aren't found.  tcl has dtrace support in its shared library, but unlike 
libmozjs.so, libtcl.so does link in tclDTrace.o.  I'm guessing the heapsort 
example is being built similar to libtcl.so.

stap -c foo foo.stp
-stap matches probes defined in foo.stp with probes defined in foo's .probes
 section
-if probe_ENABLED() is used then sdt.h will cause the foo to be built
 with a check of probe_semaphore
-stap does the work of incrementing/decrementing probe_semaphore
-otherwise static probes appear to stap to be typical user probes