[lttng-dev] lttng-ust under the hood

[Thibault, Daniel]

-----Message d'origine-----
De : Gerlando Falauto [mailto:gerlando.falauto at keymile.com] 
Envoyé : 2 juin 2014 11:18

> Thank you very much for your examples and explanations.
> I'm slowly starting to understand.
> I believe with optional linking (whereas your *USERS* need to #define both TRACEPOINT_DEFINE and TRACEPOINT_PROBE_DYNAMIC_LINKAGE), even the dependency to liblttng-ust.so and (consequently) liblttng-ust-tracepoint.so is dropped.
> This means you only need to add -ldl to your application's LDFLAGS, and the two binaries liblttng-ust.so and liblttng-ust-tracepoint.so need not be copied to the target's rootfs.
> Is that right?

   Yes, in the sense that libtp.so need not be present on the 'target rootfs' for the instrumented application to run.  But if you want the instrumented application to be traced, libtp.so must be present on the target file system (so the application can find it).

> However, I get the impression that such a feature is not available for
> tracef() (meaning, if you're using tracef(), there's no way you can optionally link to it -- the above shared objects need to be present on the target's filesystem).
> Is my understanding right? If so, is there are reason for it?

   I can't speak about tracef(): this is a more recent feature whereas I feature-froze LTTng at 2.3.0-1 in order to complete the documentation project.  I will be moving on to 2.4 and 2.5 in the near future, but for now someone else will have to act as tracef()'s advocate.  I would presume it works the same way as tracepoint(), in the sense that the instrumented application remains runnable even when the tracepoint provider shared object can't eb found.

> What I'm looking for is some way to instrument the code without touching the target filesystem unless needed.
>
> I believe this is probably against the whole idea of tracing (where you want tracing to ALWAYS be available, given its negligible overhead, as per Murphy's Law the moment it'll prove most valuable is when you least expect it to), still...

   Modifying the target file system is unavoidable, I'd think.  The applications need to be instrumented (that's one modification), and there must be support for tracing on the target: the session daemon and consumer daemon must be installed (you can omit installing the LTTng kernel modules if you only need to trace user-space) and run, and the instrumented applications' tracepoint provider must be present, either in the apps themselves (static linking) or as a shared object.  You can at least avoid storing the trace itself on the target file system, by exporting the trace data over the wire.

> Thanks a lot!
> Gerlando

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection & Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber Security (MCCS)
R & D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence R&D Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ <http://www.travelgis.com/map.asp?addr=918V%20QSDJ>
Gouvernement du Canada | Government of Canada
<http://www.valcartier.drdc-rddc.gc.ca/>