[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 05:45 PM, Mathieu Desnoyers wrote:
> > * Woegerer, Paul (Paul_Woegerer at mentor.com) wrote:
> >> 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.
> 
> But still, to come back to my original request, whenever the tracepoint
> provider is statically linked to the tracepoint user (which is a valid
> lttng-ust use case, right ?)

yes,

> it is not possible to emit tracepoints in
> object constructors as long as object constructors defined in
> lttng/tracepoint.h and lttng/ust-tracepoint-event.h are simply using
> __attribute__((constructor)) instead of e.g. __attribute__((constructor
> (1000))).

Those can be emitted, but indeed they might not be traced.

> Without this change the user simply cannot make sure its own
> constructor gets invoked after the trace provider constructors.

If we try to support tracing constructors, I'm concerned that with this
change (using priority):
1 - we lose in terms of portability (not all gcc versions support the
priority argument,
2 - there can be corner-cases that won't honor the priority.

We should thoroughly test and document the effect of priority in cases
of:

- multiple .o linked into an executable,
- multiple .o linked into a .a, statically linked (does not honor
  constructors at all),
- multiple .o linked into a .so, many .so linked,

And figure out if the ordering of constructor is OK with each of those
cases.

> 
> >> 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)).
> 
> Therefore we would need to reliably deduce the tracepoint provider
> shared library name from the header file that defines it. Since C/C++
> has no package concept and gives you the freedom to name your shared
> library whatever you like it seems to be hard to get there.

indeed,

> 
> One way to deal with it would be to extend the lttng-gen-tp tool
> directly build the tracepoint provider shared library instead of just
> outputting the generated .c .h files.

But then we'd _require_ that people use .so for providers. They might
want to just pull the probe provider into their executable.

> This way the shared library name
> would be controlled by lttng-gen-tp tool and an autogenerated macro
> (e.g. ensure_tracepoints_init()) in the generated .h file could provide
> the dlopen code to explicitly load the tracepoint provider shared
> library if needed.

Would this work fine with your constructor instrumentation use-case ?
Is the order of constructors across .so files guaranteed in any way ?

Thanks,

Mathieu

> 
> Thanks,
> 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
EfficiOS Inc.
http://www.efficios.com