[lttng-dev] Instrumenting a Shared Object

Brian Robbins brianrob at microsoft.com
Wed Aug 19 16:14:48 EDT 2015


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<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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20150819/6b5d79b6/attachment.html>


More information about the lttng-dev mailing list