This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Probes in shared libs going missing


On Fri, Jul 2, 2010 at 8:32 AM, Stan Cox <scox@redhat.com> wrote:
> 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.

Ok. I'm really only concerned with stap's dtrace emulator right now,
although I still appreciate the explanation because I had falsely
concluded that it was doing the same nop thing.

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

...except that it *is* part of the libmozjs.so link. I'm pasting the
actual compile line below, but first let me summarize it:

c++ -fPIC -shared -o libmozjs.so lots_and_lots_of_objects.o
mozjs-dtrace.o -lvarious

And yes, that is how I am linking libheapsort.so as well. (The example
on the webpage doesn't generate an intermediate shared library
libheapsort.so, so that part is my doing.)

Full link line:

c++  -fno-rtti -fno-exceptions -Wall -Wpointer-arith
-Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy
-Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof
-Wno-variadic-macros -pedantic -Wno-long-long -gdwarf-2
-fno-strict-aliasing -pthread -pipe  -DDEBUG -D_DEBUG -DDEBUG_sfink
-DTRACING -gdwarf-2 -fPIC -shared -Wl,-z,defs -Wl,-h,libmozjs.so -o
libmozjs.so  jsapi.o jsarena.o jsarray.o jsatom.o jsbool.o jscntxt.o
jsdate.o jsdbgapi.o jsdhash.o jsdtoa.o jsemit.o jsexn.o jsfun.o jsgc.o
jsgcchunk.o jshash.o jsinterp.o jsinvoke.o jsiter.o jslock.o jslog2.o
jsmath.o jsnativestack.o jsnum.o jsobj.o json.o jsopcode.o jsparse.o
jsproxy.o jsprf.o jspropertycache.o jspropertytree.o jsregexp.o
jsscan.o jsscope.o jsscript.o jsstr.o jstask.o jstypedarray.o jsutil.o
jswrapper.o jsxdrapi.o jsxml.o prmjtime.o jsdtracef.o jstracer.o
Assembler.o Allocator.o CodeAlloc.o Containers.o Fragmento.o LIR.o
njconfig.o RegAlloc.o avmplus.o NativeX64.o jsbuiltins.o VMPI.o
CTypes.o Library.o mozjs-dtrace.o    -lpthread    -Wl,-rpath-link,/bin
-Wl,-rpath-link,/lib -Wl,--whole-archive ctypes/libffi/.libs/libffi.a
-Wl,--no-whole-archive -L/home/sfink/moz-central/obj-dtrace/dist/lib
-lplds4 -lplc4 -lnspr4 -lpthread -ldl -ldl -lm  -lm -ldl


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]