[lttng-dev] Emitting events from shared object constructors is (currently) not possible

[Mathieu Desnoyers]

* Woegerer, Paul (Paul_Woegerer at mentor.com) wrote:
> On 11/22/2012 04:39 PM, Mathieu Desnoyers wrote:
> > * Woegerer, Paul (Paul_Woegerer at mentor.com) wrote:
> >> I recently stumbled over the following lttng-ust limitation:
> >>
> >> I tried to emit events from a shared objects constructor function:
> >>
> >> __attribute__((constructor))
> >> void func_constructor()
> >> {
> >>    tracepoint( foo, bar ); 
> >> }
> >>
> >> Unfortunately this doesn't work because the constructor functions of
> >> LTTng itself (__tracepoints__init and the ones from
> >> ust-tracepoint-event.h) are not yet run.
> >>
> >> Trying to solve this problem with explicit constructor priority on my
> >> side alone doesn't work:
> >>
> >> __attribute__((constructor (1111)))
> >> void func_constructor()
> >> {
> >>    tracepoint( foo, bar ); 
> >> }
> >>
> >> That's because whatever I specify as priority is irrelevant. LTTng's
> >> constructors without priority will always come last.
> >>
> >> After also adding priority to the lttng constructor I was able to make
> >> it work (see patch below):
> > 
> > Hi Paul,
> > 
> > I notice that you probably embed your probes along with your code within
> > the same shared object/executable, right ?
> > 
> > Unfortunately, this approach does not work if the probes are placed in a
> > different shared object than the program code. Here is an example:
> 
> Hi Mathieu,
> 
> In case the probes would be defined in different shared object from the
> one where they are used we wouldn't have a problem at all because the
> dynamic linker would invoke all the constructor functions for the probe
> shared object before the constructor functions of the shared object that
> has a dependency to the probe shared object, right ?

The instrumented code does not have dependency on the probe shared
object, so we can ship applications separately from their probe .so. So
unfortunately, the linker is not doing this for us.

> 
> And even if this is not the case I could explicitly dlopen the probe
> shared object from within my constructor function and thus make sure
> that the constructor function of the probe shared object gets called
> before I emit an event from my constructor function.

The idea would be to provide a nice API to facilitate this use-case, and
document it in the instrumentation guide-lines (lttng-ust(3)).

Thanks,

Mathieu

> 
> --
> Paul
> 
> -- 
> Paul Woegerer | SW Development Engineer
> http://go.mentor.com/sourceryanalyzer
> 
> Mentor Embedded(tm) | Prinz Eugen Straße 72/2/4, Vienna, 1040 Austria
> Nucleus® | Linux® | Android(tm) | Services | UI | Multi-OS
> 
> Android is a trademark of Google Inc. Use of this trademark is subject
> to Google Permissions.
> Linux is the registered trademark of Linus Torvalds in the U.S. and
> other countries.

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com