[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 12:22

>>     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).
>
>In this case (optional linking), the application won't even look for it
>-- you need to manually feed it through LD_PRELOAD libtp.so, right?

   Not quite.  In both dynamic linking cases (with and without static awareness), the tracepoint provider is sought.  In the static awareness case, it is the Linux dynamic linker (ld) that does the searching and which emits the 'error while loading shared libraries [...] No such file or directory' error message.  In the non-static awareness (static unawareness?) case, it is the application's initializer which tries to dlopen() the shared object.  The difference here is that the initializer fails quietly, flagging the tracepoints as inert.  This happens just once per shared object which the app refers to.

> Almost. I believe there's still some hard dependency on _lttng_ust_tracef(), which is defined within tracef.c and therefore ends up within liblttng-ust.so.
>
> However, moving its definition (as static inline) to tracef.h seems to do the trick.
> This way (i.e. defining TRACEPOINT_DEFINE and TRACEPOINT_PROBE_DYNAMIC_LINKAGE within my application) I end up with an application which
> a) does nothing when called normally
> b) correctly creates tracef() events when invoked with LD_PRELOAD=liblttng-ust.so
>
> I believe, that's reasonable behavior, isn't it?

   Indeed, that's what I would expect the behaviour to be.

> Yes, of course you need to have those libraries if you want to enable tracing. It'd also be nice, if you don't need tracing (for whatever
> reason) to be able to omit them, while keeping your application's binary identical.
> I assume the only conceivable reason would be to save some (though
> negligible) footprint on the target filesystem. I also understand that once the application is instrumented, unless the event is enabled, the execution overhead per tracepoint is
> exactly the same (i.e. a missed branch), regardless of whether the tracepoint provider library is loaded or not.
> In other words, using optional (dynamic) linking won't make your application run any faster. It will only save you a few Kbytes footprint on your target (liblttng-ust.so, liblttng-ust-tracepoint.so, libmytracepoint.so). Right?

   Right!

   Instrumented applications will run very slightly faster when tracing is wholly turned off, simply because the session daemon isn't "stealing" the odd CPU cycle now and then.  I would expect this to be very, very small difference.

> Thanks *A LOT* once again!
> 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/>