[lttng-dev] instrumenting shared library

[Thibault, Daniel]

De : Anand Neeli [mailto:anand.neeli at gmail.com]
Envoyé : 7 avril 2014 10:37

> - It doesn't 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 pros and cons here)

   Not quite true.  If the tracepoints are statically included in the app, then the app must be recompiled and relinked whenever the tracepoints change.  Example:

static: static.o tp.o
            @echo "~~~~~~Linking sample_$@:"
            $(CC) -o sample_$@ $^ $(LDFLAGS) $(LIBDL) $(LIBUST)
            @echo "   Use './sample_$@' to run sample_$@"

static.o: sample.c tp.h
            @echo "~~~~~~Compiling $@:"
            $(CC) $(CPPFLAGS) $(LOCAL_CPPFLAGS) $(TP_DEFINE) -c -o $@ $<

tp.o: tp.c tp.h
            @echo "~~~~~~Compiling $@:"
            $(CC) $(CPPFLAGS) $(LOCAL_CPPFLAGS) -c -o $@ $<

   Every time you change tp.h, you must recompile tp.o and static.o and relink both into a new sample_static executable image.  If you keep the tracepoint() signatures unchanged, then you may get away with not recompiling static.o-but you must still relink.

   At the other extreme, if the app explicitly loads the tracepoint provider using dlopen, then one could conceivably send a message to all apps to dlclose the tracepoint provider shared object and dlopen a replacement one (if such an API has been programmed in).  The apps wouldn't need to stop running at all.  Of course this supposes the tracepoint() signatures do not change.  (To avoid confusing babeltrace, the traces must be collected using the buffers-pid channel option and the changeover must not occur within the same one-second time window)

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

   The difference will be slight: using a dynamic link, the linker must do a little extra work when loading the tracepoint provider shared object along with the application's binary image, just because it needs to find it elsewhere. So you can expect app startup to be a little longer the first time. If the app is using a tracepoint provider shared object which happens to be already used by other running apps, the startup time actually becomes shorter because the tracepoint provider shared object is already in memory.

   Once the app is running, there should be no difference at all in performance.

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

   Sounds like a plan!

> Thanks again for spending your time on these queries.
> -Anand Neeli
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<--ESFSECEV-TY3011--------------------------------> <http://www.travelgis.com/map.asp?addr=918V%20QSDJ<--ESFSECEV-TY3011-------------------------------->>
Gouvernement du Canada | Government of Canada
<http://www.valcartier.drdc-rddc.gc.ca/<--ESFSECEV-TY3011--------------------->>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20140407/35448cd8/attachment.html>