[lttng-dev] Instrumenting a Shared Object

[Mathieu Desnoyers]

----- On Sep 9, 2015, at 4:49 PM, Brian Robbins <brianrob at microsoft.com> wrote: 

> One additional question on this. It appears that the tracepoint initialization
> code will dlopen liblttng-ust-tracepoint.so.0 and essentially no-op if it can’t
> find it. However, I’ve noticed that the executable still has a static
> dependency on liblttng-ust.so.0 and liblttng-ust-tracepoint.so.0, I believe for
> registration. Is there any way to make these static dependencies dynamic as
> well so that if liblttng-ust is not installed on an arbitrary machine, then the
> application still works but no tracing is possible?

Hi Brian, 

Yes, lttng-ust can be used either with a probe provider as a static dependency 
of the application, or entirely dynamically, in a use-case where you don't want 
requiring to deploy lttng-ust on all systems, but keep building the application with 
tracepoints. 

Both ways of doing things are documented in the lttng-ust(3) man page. I think the 
use-case you are describing fits in section 

"BUILDING/LINKING THE TRACEPOINT PROVIDER 
[...] 
2) Compile the Tracepoint Provider separately from the application, 
using dynamic linking:" 

The key thing here is to split your tracepoint probe provider from your application 
by building it into its own .so. Then, you can package the tracepoint probe provider 
into an optional package, an "add-on" to your application. The static dependency 
on lttng-ust is from the tracepoint probe provider, not the application tracepoints 
per se. 

Does it help ? 

Thanks, 

Mathieu 

> Thanks.

> -Brian

> From: Brian Robbins [mailto:brianrob at microsoft.com]
> Sent: Wednesday, August 19, 2015 1:15 PM
> To: Jérémie Galarneau <jeremie.galarneau at efficios.com>
> Cc: Rama Krishnan Raghupathy <ramarag at microsoft.com>; lttng-dev at lists.lttng.org
> Subject: Re: [lttng-dev] Instrumenting a Shared Object

> Hi Jérémie,

> Thank you very much. That helps a bunch. I think in general, we can make some
> guarantees around when tracepoints are no-longer called, so we should just be
> able to dlclose liblttng-ust after that point.

> Mathieu – if you have any additional advice, that would be great.

> Thank you much.

> -Brian

> From: jeremie.galarneau at gmail.com [ mailto:jeremie.galarneau at gmail.com ] On
> Behalf Of Jérémie Galarneau
> Sent: Monday, August 17, 2015 3:22 PM
> To: Brian Robbins < brianrob at microsoft.com >
> Cc: lttng-dev at lists.lttng.org ; Rama Krishnan Raghupathy < ramarag at microsoft.com
> >; Mathieu Desnoyers < mathieu.desnoyers at efficios.com >
> Subject: Re: [lttng-dev] Instrumenting a Shared Object

> Hi Brian,

> Mathieu will probably weigh in on this shortly. In the meantime, here's my
> understanding of the problem.

> In order to produce a trace, you have to ensure both liblttng-ust and your
> provider(s) are linked into the application. That can be done either by
> LD_PRELOAD-ing, dynamically linking, or dlopen-ing() both. Not linking against
> liblttng-ust will simply result in your application not producing a trace
> (since the application will never register to the session daemon), but will
> have no adverse effect.

> The real concern with dlclose-ing the providers is that you have to be entirely
> sure that no tracepoints will be triggered after the provider is
> unloaded/dlclose. There is no reference counting to ensure the provider remains
> loaded as long as any probes remain reachable or any other mechanism of the
> sort. Therefore, triggering a tracepoint after the provider has been unloaded
> will result in a crash. Keep in mind that triggering tracepoints remains
> entirely safe if the providers are never loaded. Only triggering after a
> dlopen/dlclose of providers may cause problems.

> If you can guarantee this doesn't happen, you should be pretty much good to go.

> Regards,

> Jérémie

> On Thu, Aug 13, 2015 at 7:40 PM, Brian Robbins < brianrob at microsoft.com > wrote:
>> Hello,

>> I’m looking to instrument a shared object using LTTng-UST tracepoints. The
>> expectation is that users of the library will use dlopen to open it at the
>> beginning of their application and dlclose right before process exit. From what
>> I’ve read at
>> http://lttng.org/docs/#doc-building-tracepoint-providers-and-user-application ,
>> it sounds like there is some complexity with this as the tracepoint definition
>> must remain in memory, but I want to make sure I fully understand.

>> If I want to instrument a shared object, is my only option to dynamically link
>> and use LD_PRELOAD? Also, do my options change if I know that the process will
>> exit right after it calls dlclose on the library?

>> Thank you very much.

>> -Brian

>> _______________________________________________
>> lttng-dev mailing list
>> lttng-dev at lists.lttng.org
>> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

> --

> Jérémie Galarneau
> EfficiOS Inc.
> http://www.efficios.com

> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

-- 
Mathieu Desnoyers 
EfficiOS Inc. 
http://www.efficios.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20150912/0d2cd7ca/attachment.html>