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" <[email protected]> To: "[email protected]" <[email protected]> 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 <[email protected]> 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 [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
_______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
