On 05/03/2013 08:35 PM, Mathieu Desnoyers wrote: > * Woegerer, Paul (paul_woege...@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. _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
