This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Probes in shared libs going missing
- From: Stan Cox <scox at redhat dot com>
- To: Steve Fink <sphink at gmail dot com>
- Cc: systemtap at sourceware dot org
- Date: Fri, 02 Jul 2010 11:32:53 -0400
- Subject: Re: Probes in shared libs going missing
- References: <4C2A8E51.4000103@mozilla.com> <4C2B9668.8060609@redhat.com> <AANLkTikKJ3kYZR8p00TXT90YM0Y40ucGEimaP5_C1SKq@mail.gmail.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