lttng-dev.lists.lttng.org archive mirror
 help / color / mirror / Atom feed
* [lttng-dev] Feature request: dynamically load from prefix
@ 2021-07-15 11:21 Norbert Lange via lttng-dev
  2021-10-05 18:28 ` Mathieu Desnoyers via lttng-dev
  0 siblings, 1 reply; 2+ messages in thread
From: Norbert Lange via lttng-dev @ 2021-07-15 11:21 UTC (permalink / raw)
  To: lttng-dev

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.

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [lttng-dev] Feature request: dynamically load from prefix
  2021-07-15 11:21 [lttng-dev] Feature request: dynamically load from prefix Norbert Lange via lttng-dev
@ 2021-10-05 18:28 ` Mathieu Desnoyers via lttng-dev
  0 siblings, 0 replies; 2+ messages in thread
From: Mathieu Desnoyers via lttng-dev @ 2021-10-05 18:28 UTC (permalink / raw)
  To: Norbert Lange; +Cc: lttng-dev

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2021-10-05 18:28 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-15 11:21 [lttng-dev] Feature request: dynamically load from prefix Norbert Lange via lttng-dev
2021-10-05 18:28 ` Mathieu Desnoyers via lttng-dev

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).