[lttng-dev] Instrumenting a Shared Object

[lttng-dev] Instrumenting a Shared Object

[Brian Robbins]

HI Mathieu,

I wanted to ask a couple of follow-up questions on this.  If you build an so containing the probe provider, do you have to then use LD_PRELOAD to load it? Ideally, we?d like to do any dynamic loading programmatically so that there?s no environment setup needed, while at the same time ensuring that the probe provider so is dynamic so that it is not required to run the application.

On a side-note, I did a bit of inspection and it looks to me like most every call from the probe definition macros is dynamic (through dlopen/dlsym).  The only ones that I saw that are static were for registration/unregistration.  Is it possible that we just did something wrong, and there is a way to make registration dynamic as well?

Thanks.
-Brian



From: Mathieu Desnoyers [mailto:mathieu.desnoyers@efficios.com]
Sent: Saturday, September 12, 2015 9:59 AM
To: Brian Robbins <brianrob at microsoft.com>
Cc: Jeremie Galarneau <jeremie.galarneau at efficios.com>; Rama Krishnan Raghupathy <ramarag at microsoft.com>; lttng-dev <lttng-dev at lists.lttng.org>
Subject: Re: [lttng-dev] Instrumenting a Shared Object

----- On Sep 9, 2015, at 4:49 PM, Brian Robbins <brianrob at microsoft.com<mailto: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@microsoft.com]
Sent: Wednesday, August 19, 2015 1:15 PM
To: J?r?mie Galarneau <jeremie.galarneau at efficios.com<mailto:jeremie.galarneau at efficios.com>>
Cc: Rama Krishnan Raghupathy <ramarag at microsoft.com<mailto:ramarag at microsoft.com>>; lttng-dev at lists.lttng.org<mailto: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@gmail.com<mailto:jeremie.galarneau@gmail.com> [mailto:jeremie.galarneau@gmail.com] On Behalf Of J?r?mie Galarneau
Sent: Monday, August 17, 2015 3:22 PM
To: Brian Robbins <brianrob at microsoft.com<mailto:brianrob at microsoft.com>>
Cc: lttng-dev at lists.lttng.org<mailto:lttng-dev at lists.lttng.org>; Rama Krishnan Raghupathy <ramarag at microsoft.com<mailto:ramarag at microsoft.com>>; Mathieu Desnoyers <mathieu.desnoyers at efficios.com<mailto: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<mailto: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<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flttng.org%2fdocs%2f%23doc-building-tracepoint-providers-and-user-application&data=01%7c01%7cbrianrob%40microsoft.com%7c3ae11714ef9b4072f3ee08d2a75249b9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=YO4WlsmA6UBLU%2fvAmnn6JL4S5JnsXWguw%2bXgkC2M9aI%3d>, 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<mailto:lttng-dev at lists.lttng.org>
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.lttng.org%2fcgi-bin%2fmailman%2flistinfo%2flttng-dev&data=01%7c01%7cbrianrob%40microsoft.com%7c3ae11714ef9b4072f3ee08d2a75249b9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=kvzDR%2b%2bP1EKVMNduwrayFrWR2zqBlH8OF71zm0sA8eQ%3d>


--
J?r?mie Galarneau
EfficiOS Inc.
http://www.efficios.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.efficios.com&data=01%7c01%7cbrianrob%40microsoft.com%7c3ae11714ef9b4072f3ee08d2a75249b9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3a%2bQApyhm%2bk4UaN%2fn1a0f8SS%2bn6e0Nq4B2YJGqgkpzs%3d>

_______________________________________________
lttng-dev mailing list
lttng-dev at lists.lttng.org<mailto: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/20150928/b746251e/attachment-0001.html>