----- On Jul 15, 2021, at 7:21 AM, lttng-dev lttng-dev@lists.lttng.org wrote:
> Hello, > > The production rootfs should be untouched, ideally read-only, > for development/tests a subdirectory can be mounted (eg. /usr/local). > Idea is that the contents of that directory alone (and at most some > env variables) > should allow enabling development features. > > For lttng I would have wanted to add a library > '/usr/local/lib/libmyservice-tracepoints.so' with runpath > '/usr/local/lib' that would activate lttng tracing, > pulling in lttng libraries (ust, ust-tracepoint) from /usr/local/lib. > > There is a caveat though, unless 'libmyservice-tracepoints.so'' is > preloaded, the code in lttng/tracepoint.h will run constructor functions > to register the tracepoint probes, trying to dlopen the lttng-ust-tracepoint > library and fail at that because this is not in the library search paths. > > At a later time, 'libmyservice-tracepoints.so'' will be loaded, and > lttng-ust-tracepoint (along with lttng-ust) can be resolved. but the > tracepoints are not registered. > > So I guess what I would need is to either retrigger the registration > of tracepoints > (likely complicated with static and weak symbols potentially causing a mess), > or > redirect the dlopen function. > Useful would be either try to find the library in /usr/local/lib or > use '/usr/local/lib/libmyservice-tracepoints.so'' > instead of lttng-ust-tracepoint (both have (dis)advantages). > > At any rate, I would welcome some customization macro. I'm currently working on improvements to the reporting of such scenario. See: https://review.lttng.org/c/lttng-ust/+/6480 tracepoints: print debug message when lttng-ust-tracepoint.so is not found https://review.lttng.org/c/lttng-ust/+/6484 tracepoints: increase dlopen failure message level from debug to critical With this in place, it should be easier for a lttng end-user to figure out that liblttng-ust-tracepoint.so cannot be found by dlopen() because it is not in the system's library search path. >From that point, what is wrong with requesting the user to add the path towards liblttng-ust-tracepoint.so to the environment variable LD_LIBRARY_PATH when running the application ? Thanks, Mathieu > > For illustration the current hack-around is following > > Norbert Lange > > #define TRACEPOINT_DEFINE > #define TRACEPOINT_PROBE_DYNAMIC_LINKAGE > > #include <dlfcn.h> > > static inline void *s_remap_dlopen(const char *localfilename, int > flags, unsigned prelen) { > void *md = (dlopen)(localfilename + prelen, flags); > return md ? md : (dlopen)(localfilename, flags); > } > > # ideally this would be LTTNG_TRACEPOINT_PROBE_DLOPEN instead of the dlopen > mess > #define dlopen(x, y) s_remap_dlopen("/usr/local/lib/" x, y, > (unsigned)sizeof("/usr/local/lib/") - 1U) > > #include "trace_mytracepoints.h" > _______________________________________________ > lttng-dev mailing list > lttng-dev@lists.lttng.org > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev