[lttng-dev] instrumenting shared library

[Anand Neeli]

Hi Daniel,
I had spend sometime and compiled
Non-Instrumented app with static instrumented library
Non-Instrumented app with dynamic instrumented library
Instrumented app with static instrumented library
Instrumented app with dynamic instrumented library

Thanks for your help.

- It doest matter if the tracepoints are static or dynamically loaded with
the app. Once there is a change in tracepoints the app should be reloaded
(even though not compiled). Even though the tracepoints can be shared, but
changing tracepoints we would need to restart all the app's which share the
tracepoints.
(Just trying to make a statement on procs and cons here)


- * Does static or dynamic inclusion make difference(in terms of
performance) if someone always want to run in tracing mode??

Now let me put some light on how someone would like to use lttngin huge
codebases. (this is my personal opinion)
- Normally tracepoints are made per component/daemon. And not shared across
daemons/components.
- Tracing should always be running. It should never be switched off.
(unless the application is not mission critical)
- I'm planning to always run memory(snapshot) tracing with some fixed size
buffer, which can capture last n-events or n-bytes
- Above memory tracing users can create another tracing session and dump
traces to files if needed.(with their own filters and context in
enable-event)


Thanks again for spending your time on these queries.
-Anand Neeli





On Mon, Apr 7, 2014 at 6:53 PM, Thibault, Daniel <
Daniel.Thibault at drdc-rddc.gc.ca> wrote:

>     You need to define your concept of operations carefully.
>
>
>
>    An instrumented application can include its tracepoint provider in
> several ways.
>
>
>
>    One is static inclusion: the application will always be traceable, but
> any change to the tracepoints requires a recompilation of the app, plus the
> tracepoint events it produces should not be shared with any other
> application (I say 'should' because they can, but it's a bad idea to do so).
>
>
>
>    Another is dynamic inclusion with static awareness: the application
> will always be traceable, but will refuse to run if does not find the
> tracepoint provider library (typically provided by LD_PRELOAD). The
> tracepoint events can be shared with other applications.
>
>
>
>    The third is dynamic inclusion without static awareness: this operates
> as the previous, except that when the app does not find the tracepoint
> provider it runs normally but is not traceable. Turning off traceability in
> this way does give you a very small gain in performance.
>
>
>
>    The last is fully dynamic inclusion: the app is responsible for its own
> traceability because it loads and unloads its tracepoint provider itself
> (using dlopen and dlclose). This is more intrusive as the app's code needs
> to include this aspect, possibly reflected in its user interface (by a menu
> item, for instance). On the good side it does mean you get the slight
> performance gain on demand.
>
>
>
>    If the very slight loss of performance due to tracing doesn't bother
> you, your best bet is probably dynamic inclusion without static awareness
> (third option). LTTng can then be configured to capture your app's traces
> using an on-disc circular buffer (see the tracefile-size and
> tracefile-count options of the enable-channel command). When your app
> misbehaves, you suspend it, suspend tracing (lttng stop), and copy the
> trace to a working directory. You can then babeltrace it or use the Eclipse
> LTTng views to analyse the trace. This works even better if your app is run
> multiple times, because then LTTng will capture each running separately
> (see the buffers-pid and buffers-uid options of the enable-channel
> command). You only need to remember to flush the older traces once you've
> decided you don't need them anymore.
>
>
>
> 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> <*http://www.travelgis.com/map.asp?addr=918V%20QSDJ
> <http://www.travelgis.com/map.asp?addr=918V%20QSDJ>*>
> Gouvernement du Canada | Government of Canada
> <http://www.valcartier.drdc-rddc.gc.ca/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20140407/06c7c0d7/attachment-0001.html>