[lttng-dev] instrumenting shared library

Jérémie Galarneau jeremie.galarneau at efficios.com
Fri Apr 4 10:46:09 EDT 2014


On Fri, Apr 4, 2014 at 1:44 AM, Anand Neeli <anand.neeli at gmail.com> wrote:
> Hi Daniel,
> Thanks for your reply.
> sorry for my ignorance but how are you generating libtp.so in your example?
>
> 1) Also will this solution scale if my binary depends on lots of libraries
> which are instrumented?
>

It should have no impact on scalability.

> 2) i'm fine with linking statically, can we avoid LD_PRELOAD?
>

Absolutely, you can link the providers in your application directly.
The advantage of using LD_PRELOAD is to make sure your application has
no dependency on lttng-ust.so.

Please refer to the "BUILDING/LINKING THE TRACEPOINT PROVIDER" section
in the LTTNG-UST(3) man page.

The lttng-ust/doc/examples/ folder also contains Makefiles to show you
how to link tracepoints providers to your application either
statically or dynamically.

> 3) Is there any page which explains on why and how to use
> TRACEPOINT_PROVIDER, TRACEPOINT_CREATE_PROBES, TRACEPOINT_INCLUDE,
> TRACEPOINT_DEFINE, TRACEPOINT_PROBE_DYNAMIC_LINKAGE
>

Not really. Hopefully I'll make this clear without delving in
implementation details...

TRACEPOINT_PROVIDER must be defined to the name of your tracepoint provider.

TRACEPOINT_INCLUDE must provide a path to the current include file.

TRACEPOINT_PROBE_DYNAMIC_LINKAGE is pretty self explanatory. It will
make sure that no unresolved symbols are emited by lttng/tracepoint.h.
This way the tracee can be built without having to resolve a symbol
defined in the provider.

TRACEPOINT_DEFINE, as noted in the lttng-ust manpage, should be
defined before you include the tracepoint headers in the .c file where
they'll be used.

TRACEPOINT_CREATE_PROBES will be expanded to everything that is needed
in your provider object.

Again, taking a look at the examples should help you make sense of how
to instrument an application.

Regards,
Jérémie

>
> my tp.h is, are there any errors in this?
> #############
> #define TRACEPOINT_PROVIDER sample_component
>
> #undef TRACEPOINT_INCLUDE
> #define TRACEPOINT_INCLUDE "./tp.h"
>
> #if !defined(_TP_H) || defined(TRACEPOINT_HEADER_MULTI_READ)
> #define _TP_H
>
> #include <lttng/tracepoint.h>
>
> TRACEPOINT_EVENT(
>         sample_component,
>         event,
>         TP_ARGS(char *, text),
>         TP_FIELDS(
>                 ctf_string(message, text)
>         )
> )
> TRACEPOINT_LOGLEVEL(
>         sample_component,
>         event,
>         TRACE_WARNING)
>
> #endif /* _TP_H */
> #include <lttng/tracepoint-event.h>
> #############
>
>
>
> Thanks,
> Anand Neeli
>
>
> On Thu, Apr 3, 2014 at 9:35 PM, Thibault, Daniel
> <Daniel.Thibault at drdc-rddc.gc.ca> wrote:
>>
>> ----------------------------------------------------------------------
>> Date: Thu, 3 Apr 2014 16:55:38 +0530
>> From: Anand Neeli <anand.neeli at gmail.com>
>> To: "lttng-dev at lists.lttng.org" <lttng-dev at lists.lttng.org>
>>
>> > I have a library which is instrumented and tracepoints are added. And I
>> > have 2 binary's (or daemons) which try to include this library. (one
>> > binary
>> > has instrumented code with tracepoints and other binary doesn't use
>> > tracing)
>> >
>> > I found that i need to instrument the daemon which includes the
>> > instrumented library for the code to compile.
>> >
>> > Can't I have a daemon (without tracing functionality) which can include
>> > an
>> > instrumented library (i don't want to use tracing functionality in this
>> > case)
>> >
>> > I'm only able to build if both library and daemon which includes it are
>> > instrumented.
>> >
>> > Can anyone please give me more details on how to do this?
>> > This is useful for huge code bases where you can selectively add tracing
>> > support to few libraries or daemons.
>> >
>> > Anand Neeli
>>
>>    It can be done.  An uninstrumented app can rely on an instrumented
>> shared object; whether the latter produces lttng events then depends on
>> whether or not the tracepoint provider shared object is loaded when the app
>> is invoked (using LD_PRELOAD).
>>
>>    Here is sample_neeli.c:
>> #####
>> #include <stdio.h> //For printf
>> #include <unistd.h>
>>
>> #include "cobject.h"
>> int main(int argc, char **argv)
>> {
>>         int i = 0;
>>         char themessage[20]; //Can hold up to "Hello World 9999999\0"
>>
>>         fprintf(stderr, "sample_neeli starting\n");
>>         for (i = 0; i < 10000; i++) {
>>                 //We either prepare themessage in this module, or rely on
>> an
>>                 //external shared object
>>                 cobject_message(themessage, i);
>>                 usleep(1);
>>         }
>>         fprintf(stderr, "sample_neeli done\n");
>>         return 0;
>> }
>> #####
>> cobject.c:
>> #####
>> #include <stdio.h> //For printf
>> #include <unistd.h>
>>
>> #include "tp.h"
>>
>> void cobject_message(char *themessage, int i)
>> {
>>         tracepoint(sample_component, event, "cobject_message");
>>         sprintf(themessage, "CObject %u", i);
>> }
>> #####
>> cobject.h:
>> #####
>> extern void cobject_message(char *themessage, int i);
>> #####
>> The tracepoint provider code should be easy to guess.
>>
>> The relevant Makefile fragments:
>> #####
>> CC = gcc
>> LIBDL = -ldl # On Linux
>> #LIBDL = -lc # On BSD
>> LOCAL_CPPFLAGS += -I. $(AM_CPPFLAGS)
>> LDFLAGS += -L/usr/local/lib $(AM_LDFLAGS)
>> SOFLAGS = -fPIC
>> TP_DEFINE = -D TRACEPOINT_DEFINE
>> TP_DEFINE_DYNAMIC = $(TP_DEFINE) -D TRACEPOINT_PROBE_DYNAMIC_LINKAGE
>> SOVERSION_MAJOR = 1
>> SOVERSION_MINOR = 0
>>
>> libcobject.so: libcobject.o
>>         @echo "~~~~~~Packaging $@:"
>>         $(CC) -shared -Wl,-soname,$@.$(SOVERSION_MAJOR) -Wl,-no-as-needed
>> \
>>            -o $@.$(SOVERSION_MAJOR).$(SOVERSION_MINOR) $^
>>         ln -sf $@.$(SOVERSION_MAJOR).$(SOVERSION_MINOR)
>> $@.$(SOVERSION_MAJOR)
>>         ln -sf $@.$(SOVERSION_MAJOR) $@
>>
>> libcobject.o: cobject.c cobject.h tp.h
>>         @echo "~~~~~~Compiling $@:"
>>         $(CC) $(CPPFLAGS) $(LOCAL_CPPFLAGS) $(SOFLAGS)
>> $(TP_DEFINE_DYNAMIC) \
>>            -c -o $@ $<
>>
>> neeli_dynamic_lib:: neeli_dynamic_lib.o
>>         @echo "~~~~~~Linking sample_$@:"
>>         $(CC) -Wl,-no-as-needed -o $@ -L. -lcobject $^ $(LDFLAGS) \
>>            $(LIBDL) -Wl,-rpath,'$$ORIGIN',--enable-new-dtags
>>         @echo "   Use '[LD_PRELOAD=./libtp.so] ./$@' to run $@"
>>
>> neeli_dynamic_lib.o: sample_neeli.c cobject.h
>>         @echo "~~~~~~Compiling $@:"
>>         $(CC) $(CPPFLAGS) $(LOCAL_CPPFLAGS) -c -o $@ $<
>> #####
>>
>>    Running './neeli_dynamic_lib' yields no events.  Running
>> 'LD_PRELOAD=./libtp.so ./neeli_dynamic_lib' yields the libcobject.so events.
>>
>> 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/>
>
>
>
> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>



-- 
Jérémie Galarneau
EfficiOS Inc.
http://www.efficios.com



More information about the lttng-dev mailing list