[lttng-dev] UST - Is it possible to merge my source file and the tracepoint file?

Wed Oct 23 02:58:13 EDT 2013

Hi,

> Presumably source.c contains at least the tracepoint() calls?

Not at first. This file begins as a simple C file, and my instrumentor is 
parsing it, automatically generating source_tp.h and source_tp.c, and then 
embeds the #include line and the tracepoint() calls into source.c itself.

> Do you wish the tracepoint provider (lttng_tp_hdr.h + lttng_tp_src.c) to 
be statically included in each linked object (possibly through a shared 
static library (.a))

I want to compile a single C file into a single object file, so that I do 
not need to change anything in my project's existing build, except to tell 
it to use my automated instrumentation tool before compiling.

Here's what I mean -

In the standard work mode, I use 2 C files: (1) my source.c which 
contains:

Headers + Declarations
Include of source_tp.h (which gives declarations tracepoint functions 
__tracepoint_cb_<provider>___<tp-name>() among other things)
My own function definitions with calls to tracepoint()

And (2) is source_tp.c which contains (by defining TRACEPOINT_DEFINE and 
including source_tp.h):

Various declarations
Definitions, for example the functions named 
__tracepoint_cb_<provider>___<tp-name>(), etc.

This means that I need to add source_tp.c as a dependency of my build and 
explain how to create it, but also, to have manually added the 
tracepoint() calls and the include of source_tp.h.

What I would like, is to take a pre-processed version of source.c (after 
cpp but before the addition of tracepoint calls), and to end up with a new 
file that contains:

Headers + Declarations
Declarations of tracepoint functions 
__tracepoint_cb_<provider>___<tp-name>() among other things)
My own function definitions with the macro calls to tracepoint() already 
"unrolled".
Lttng function definitions, i.e. the functions named 
__tracepoint_cb_<provider>___<tp-name>(), etc.

This file can then be compiled directly to a single .o file which contains 
everything I need, and is a single unit containing my code and tracepoint 
provider code.

Right now, I have a working instrumentor, which requires a rather complex 
(read - slow...) procedure in order to end up with a unified .o file.

I am looking to streamline this process and make it faster.

Amit Margalit
IBM XIV - Storage Reinvented
XIV-NAS Development Team
Tel. 03-689-7774
Fax. 03-689-7230

From:   "Thibault, Daniel" <Daniel.Thibault at drdc-rddc.gc.ca>
To:     "lttng-dev at lists.lttng.org" <lttng-dev at lists.lttng.org>
Date:   10/22/2013 10:31 PM
Subject:        Re: [lttng-dev] UST - Is it possible to merge my source 
file and the tracepoint file?

-----Message d'origine-----
Date: Mon, 21 Oct 2013 16:16:30 +0300
From: Amit Margalit <AMITM at il.ibm.com>

Consider the following situation:

I wrote a header (lttng_tp_hdr.h) containing several tracepoints, matching 
some locations I want to instrument in one of my source files (let's call 
it source.c). I created a C file for this header (lttng_tp_src.c) and 
compiled it into object. I then compiled source.c into source.o and I link 
the two objects together.

This is the standard work mode.

Now I want to automate this procedure, which will cause me to generate new 
C files, and new headers for many of my sources.

How can I rewrite my source.c so it contains everything I need?

Amit Margalit
------------------------------
   Presumably source.c contains at least the tracepoint() calls?  Do you 
wish the tracepoint provider (lttng_tp_hdr.h + lttng_tp_src.c) to be 
statically included in each linked object (possibly through a shared 
static library (.a)), or would you rather have your various objects all 
share a tracepoint provider library (.so)?  In the latter case, would you 
prefer the tracepoint provider library to be a dependency (static 
awareness: the instrumented apps won't run at all unless they can find the 
.so) or not (meaning you'll need to LD_PRELOAD the .so to turn tracing 
on)?  (There's also the case where the apps control their own traceability 
by using dlopen() and dlclose() with the tracepoint provider .so)

   Typically, you need add just the tracepoint() calls and an "#include 
tracepointprovider.h" in the sources, and you control compilation with the 
-D TRACEPOINT_DEFINE and -D TRACEPOINT_PROBE_DYNAMIC_LINKAGE switches.

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/>
 LinkedIn: <http://ca.linkedin.com/in/daniel-u-thibault/>
 Research Gate: <https://www.researchgate.net/profile/Daniel_Thibault/>

_______________________________________________
lttng-dev mailing list
lttng-dev at lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20131023/6a1a8894/attachment.html>