* Woegerer, Paul ([email protected]) wrote: > On 11/22/2012 05:45 PM, Mathieu Desnoyers wrote: > > * Woegerer, Paul ([email protected]) 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 _______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
