[lttng-dev] lttng-ust under the hood

[Gerlando Falauto]

Hi Daniel,

On 06/02/2014 05:39 PM, Thibault, Daniel wrote:
> -----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).

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?

>> 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.

Almost. I believe there's still some hard depedency 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?

>
>> 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.

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 the exactly 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?

Thanks *A LOT* once again!
Gerlando

>
>> 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/>
>