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


Sorry, I'm dense.

(And I lied; I'm not actually trying to build firefox yet, just the js
executable. But I'll want firefox next.)

From what I can tell, your PROGOBJS += mozjs-dtrace.o workaround would
work for me, because it works when I do the equivalent on the command
line.

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?

What does it mean for a static variable to be generated by dtrace -G?
I am used to static variables being restricted to a compilation unit,
and independent .o files in a link command are all separate
compilation units; static variables in one are invisible to the
others.

Unless *_ENABLED() is actually a function call that reads that static
variable's value? In which case it makes sense to my naive
understanding (because the function is being exported, not the static
variable), but in that case *_ENABLED() should pull in the static
variable when included in a partial link to generate the shared
object, no?

And why would it behave differently in the heapsort example? (Or
specifically, the heapsort example modified to generate a
libheapsort.so containing heapsort.o and probes.o before being linked
into the final binary.)

Sorry for all the questions when you've already given me a workable
fix, but I'd really like to understand what's happening.

On Wed, Jun 30, 2010 at 12:09 PM, Stan Cox <scox@redhat.com> wrote:
> On 06/29/2010 08:22 PM, Steve Fink wrote:
>>
>> I'm having problems building firefox with static user probes.
>
> Xulrunner 1.9.1.4 is built as part of the testsuite. ?To support the
> *_ENABLED mechanism, there is a static variable corresponding to each probe.
> ?These variables are defined by 'dtrace -G -s foo.d' -> foo.o. ?When a probe
> is fired in stap, then that variable is incremented by stap itself, so that
> a check for if (*_ENABLED()) is actually checking that variables value.
>
> So when a shared object is created that has probes that require ?semaphore
> variables used to implement *_ENABLED then the corresponding object where
> those variables are defined is needed, but it isn't linked in. ?So what the
> testsuite build does is:
> ?../src/configure ...
> sed -i '/include.*rules.mk/a\
> PROGOBJS+=mozjs-dtrace.o' js/src/Makefile
>
>


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