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

[Woegerer, Paul]

On 05/03/2013 08:35 PM, Mathieu Desnoyers wrote:
> * Woegerer, Paul (Paul_Woegerer at mentor.com) wrote:
>> 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.

You are right. Using the priority construct might cause more problems
than it solves.

A pragmatic solution to the above problem would be to provide a special
documented function (as part of man:lttng-ust) that allows the user to
ensure that the static constructors (withing the same "dynamic linker
unit" (.so or exe)) used by lttng-ust have been executed successfully.
Something like:

void ensure_lttng_ust_init_completed();

If the trace provider constructors have been invoked already the
function simply returns otherwise it invokes them explicitly and makes
sure that a later invocation by the dynamic linker will not have any effect.

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

Only if we use dlopen *exclusively* and do not rely on any linker
induced shared object loading (-lfoo -lbar) anymore we would have full
control over the order of execution.

--Paul

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


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