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

[Woegerer, Paul]

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 ?) 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))). Without this change the user simply cannot make sure its own
constructor gets invoked after the trace provider constructors.

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

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

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.