8286e568b64ec915280aae67d1c589261fdb7545
[lttng-ust.git] / doc / man / lttng-ust.3
1 .TH "LTTNG-UST" "3" "February 16, 2012" "" ""
2
3 .SH "NAME"
4 lttng-ust \(em Linux Trace Toolkit Next Generation User-Space Tracer 2.x
5
6 .SH "SYNOPSIS"
7
8 .PP
9 .nf
10 Link liblttng-ust.so with applications, following this manpage.
11 .fi
12 .SH "DESCRIPTION"
13
14 .PP
15 LTTng-UST, the Linux Trace Toolkit Next Generation Userspace Tracer, is
16 port of the low-overhead tracing capabilities of the LTTng kernel tracer
17 to user-space. The library "liblttng-ust" enables tracing of
18 applications and libraries.
19
20 .SH "USAGE"
21 .PP
22 The simple way to generate the lttng-ust tracepoint probes is to use the
23 lttng-gen-tp(1) tool. See the lttng-gen-tp(1) manpage for explanation.
24 .PP
25
26 .PP
27 Here is the way to do it manually, without the lttng-gen-tp(1) helper
28 script, through an example:
29 .PP
30
31 .SH "CREATION OF TRACEPOINT PROVIDER"
32
33 .nf
34
35 To create a tracepoint provider, within a build tree similar to
36 examples/easy-ust installed with lttng-ust documentation, a
37 sample_component_provider.h for the general layout. This manpage will
38 focus on the various types that can be recorded into a trace event:
39
40 TRACEPOINT_EVENT(
41 /*
42 * provider name, not a variable but a string starting with a
43 * letter and containing either letters, numbers or underscores.
44 * Needs to be the same as TRACEPOINT_PROVIDER. Needs to
45 * follow the namespacing guide-lines in lttng/tracepoint.h:
46 *
47 * Must be included before include tracepoint provider
48 * ex.: project_event
49 * ex.: project_component_event
50 *
51 * Optional company name goes here
52 * ex.: com_efficios_project_component_event
53 *
54 * In this example, "sample" is the project, and "component" is the
55 * component.
56 */
57 sample_component,
58
59 /*
60 * tracepoint name, same format as sample provider. Does not
61 * need to be declared before. in this case the name is
62 * "message"
63 */
64 message,
65
66 /*
67 * TP_ARGS macro contains the arguments passed for the tracepoint
68 * it is in the following format
69 * TP_ARGS(type1, name1, type2, name2, ... type10,
70 name10)
71 * where there can be from zero to ten elements.
72 * typeN is the datatype, such as int, struct or double **.
73 * name is the variable name (in "int myInt" the name would be
74 * myint)
75 * TP_ARGS() is valid to mean no arguments
76 * TP_ARGS(void) is valid too
77 */
78 TP_ARGS(int, anint, int, netint, long *, values,
79 char *, text, size_t, textlen,
80 double, doublearg, float, floatarg),
81
82 /*
83 * TP_FIELDS describes how to write the fields of the trace event.
84 * You can put expressions in the "argument expression" area,
85 * typically using the input arguments from TP_ARGS.
86 */
87 TP_FIELDS(
88 /*
89 * ctf_integer: standard integer field.
90 * args: (type, field name, argument expression)
91 */
92 ctf_integer(int, intfield, anint)
93 ctf_integer(long, longfield, anint)
94
95 /*
96 * ctf_integer_hex: integer field printed as hexadecimal.
97 * args: (type, field name, argument expression)
98 */
99 ctf_integer_hex(int, intfield2, anint)
100
101 /*
102 * ctf_integer_network: integer field in network byte
103 * order. (_hex: printed as hexadecimal too)
104 * args: (type, field name, argument expression)
105 */
106 ctf_integer_network(int, netintfield, netint)
107 ctf_integer_network_hex(int, netintfieldhex, netint)
108
109 /*
110 * ctf_array: a statically-sized array.
111 * args: (type, field name, argument expression, value)
112 */
113 ctf_array(long, arrfield1, values, 3)
114
115 /*
116 * ctf_array_text: a statically-sized array, printed as
117 * a string. No need to be terminated by a null
118 * character.
119 * Behavior is undefined if "text" field is NULL.
120 */
121 ctf_array_text(char, arrfield2, text, 10)
122
123 /*
124 * ctf_sequence: a dynamically-sized array.
125 * args: (type, field name, argument expression,
126 * type of length expression, length expression)
127 * The "type of length expression" needs to be an
128 * unsigned type. As a reminder, "unsigned char" should
129 * be preferred to "char", since the signedness of
130 * "char" is implementation-defined.
131 * Behavior is undefined if "text" field is NULL.
132 */
133 ctf_sequence(char, seqfield1, text,
134 size_t, textlen)
135
136 /*
137 * ctf_sequence_text: a dynamically-sized array, printed
138 * as string. No need to be null-terminated.
139 * Behavior is undefined if "text" field is NULL.
140 */
141 ctf_sequence_text(char, seqfield2, text,
142 size_t, textlen)
143
144 /*
145 * ctf_string: null-terminated string.
146 * args: (field name, argument expression)
147 * Behavior is undefined if "text" field is NULL.
148 */
149 ctf_string(stringfield, text)
150
151 /*
152 * ctf_float: floating-point number.
153 * args: (type, field name, argument expression)
154 */
155 ctf_float(float, floatfield, floatarg)
156 ctf_float(double, doublefield, doublearg)
157 )
158 )
159 .fi
160
161 .SH "ASSIGNING LOGLEVEL TO EVENTS"
162
163 .nf
164
165 Optionally, a loglevel can be assigned to a TRACEPOINT_EVENT using the
166 following construct:
167
168 TRACEPOINT_LOGLEVEL(< [com_company_]project[_component] >,
169 < event >, < loglevel_name >)
170
171 The first field is the provider name, the second field is the name of
172 the tracepoint, and the third field is the loglevel name. A
173 TRACEPOINT_EVENT should be declared prior to the the TRACEPOINT_LOGLEVEL
174 for a given tracepoint name. The TRACEPOINT_PROVIDER must be already
175 declared before declaring a TRACEPOINT_LOGLEVEL.
176
177 The loglevels go from 0 to 14. Higher numbers imply the most verbosity
178 (higher event throughput expected.
179
180 Loglevels 0 through 6, and loglevel 14, match syslog(3) loglevels
181 semantic. Loglevels 7 through 13 offer more fine-grained selection of
182 debug information.
183
184 TRACE_EMERG 0
185 system is unusable
186
187 TRACE_ALERT 1
188 action must be taken immediately
189
190 TRACE_CRIT 2
191 critical conditions
192
193 TRACE_ERR 3
194 error conditions
195
196 TRACE_WARNING 4
197 warning conditions
198
199 TRACE_NOTICE 5
200 normal, but significant, condition
201
202 TRACE_INFO 6
203 informational message
204
205 TRACE_DEBUG_SYSTEM 7
206 debug information with system-level scope (set of programs)
207
208 TRACE_DEBUG_PROGRAM 8
209 debug information with program-level scope (set of processes)
210
211 TRACE_DEBUG_PROCESS 9
212 debug information with process-level scope (set of modules)
213
214 TRACE_DEBUG_MODULE 10
215 debug information with module (executable/library) scope (set of
216 units)
217
218 TRACE_DEBUG_UNIT 11
219 debug information with compilation unit scope (set of functions)
220
221 TRACE_DEBUG_FUNCTION 12
222 debug information with function-level scope
223
224 TRACE_DEBUG_LINE 13
225 debug information with line-level scope (TRACEPOINT_EVENT default)
226
227 TRACE_DEBUG 14
228 debug-level message (trace_printf default)
229
230 See lttng(1) for information on how to use LTTng-UST loglevels.
231
232 .fi
233
234 .SH "ADDING TRACEPOINTS TO YOUR CODE"
235
236 .nf
237
238 Include the provider header in each C files you plan to instrument,
239 following the building/linking directives in the next section.
240
241 For instance, add within a function:
242
243 tracepoint(ust_tests_hello, tptest, i, netint, values,
244 text, strlen(text), dbl, flt);
245
246 As a call to the tracepoint. It will only be activated when requested by
247 lttng(1) through lttng-sessiond(8).
248
249 Even though LTTng-UST supports tracepoint() call site duplicates having
250 the same provider and event name, it is recommended to use a
251 provider event name pair only once within the source code to help
252 mapping events back to their call sites when analyzing the trace.
253 .fi
254
255 .SH "BUILDING/LINKING THE TRACEPOINT PROVIDER"
256
257 .nf
258 There are 2 ways to compile the Tracepoint Provider with the
259 application: either statically or dynamically. Please follow
260 carefully:
261
262 1.1) Compile the Tracepoint provider with the application, either
263 directly or through a static library (.a):
264 - Into exactly one object of your application: define
265 "TRACEPOINT_DEFINE" and include the tracepoint provider.
266 - Use "\-I." for the compilation unit containing the tracepoint
267 provider include (e.g. tp.c).
268 - Link application with "\-ldl".
269 - If building the provider directly into the application,
270 link the application with "\-llttng-ust".
271 - If building a static library for the provider, link the static
272 library with "\-llttng-ust".
273 - Include the tracepoint provider header into all C files using
274 the provider.
275 - Example:
276 - tests/hello/ hello.c tp.c ust_tests_hello.h Makefile.example
277
278 2) Compile the Tracepoint Provider separately from the application,
279 using dynamic linking:
280 - Into exactly one object of your application: define
281 "TRACEPOINT_DEFINE" _and_ also define
282 "TRACEPOINT_PROBE_DYNAMIC_LINKAGE", then include the tracepoint
283 provider header.
284 - Include the tracepoint provider header into all instrumented C
285 files that use the provider.
286 - Compile the tracepoint provider with "\-I.".
287 - Link the tracepoint provider with "\-llttng-ust".
288 - Link application with "\-ldl".
289 - Set a LD_PRELOAD environment to preload the tracepoint provider
290 shared object before starting the application when tracing is
291 needed. Another way is to dlopen the tracepoint probe when needed
292 by the application.
293 - Example:
294 - doc/examples/demo demo.c tp*.c ust_tests_demo*.h demo-trace
295
296 - Note about dlclose() usage: it is not safe to use dlclose on a
297 provider shared object that is being actively used for tracing due
298 to a lack of reference counting from lttng-ust to the used shared
299 object.
300 - Enable instrumentation and control tracing with the "lttng" command
301 from lttng-tools. See lttng-tools doc/quickstart.txt.
302 - Note for C++ support: although an application instrumented with
303 tracepoints can be compiled with g++, tracepoint probes should be
304 compiled with gcc (only tested with gcc so far).
305
306 .fi
307
308 .SH "USING LTTNG UST WITH DAEMONS"
309
310 .nf
311 Some extra care is needed when using liblttng-ust with daemon
312 applications that call fork(), clone(), or BSD rfork() without a
313 following exec() family system call. The library "liblttng-ust-fork.so"
314 needs to be preloaded for the application (launch with e.g.
315 LD_PRELOAD=liblttng-ust-fork.so appname).
316
317 .fi
318
319 .SH "CONTEXT"
320
321 .PP
322 Context information can be prepended by the tracer before each, or some,
323 events. The following context information is supported by LTTng-UST:
324 .PP
325
326 .PP
327 .IP "vtid"
328 Virtual thread ID: thread ID as seen from the point of view of the
329 process namespace.
330 .PP
331
332 .PP
333 .IP "vpid"
334 Virtual process ID: process ID as seen from the point of view of the
335 process namespace.
336 .PP
337
338 .PP
339 .IP "procname"
340 Thread name, as set by exec() or prctl(). It is recommended that
341 programs set their thread name with prctl() before hitting the first
342 tracepoint for that thread.
343 .PP
344
345 .PP
346 .IP "pthread_id"
347 Pthread identifier. Can be used on architectures where pthread_t maps
348 nicely to an unsigned long type.
349 .PP
350
351 .SH "ENVIRONMENT VARIABLES"
352
353 .PP
354 .IP "LTTNG_UST_DEBUG"
355 Activate liblttng-ust debug output.
356 .PP
357 .IP "LTTNG_UST_REGISTER_TIMEOUT"
358 The environment variable "LTTNG_UST_REGISTER_TIMEOUT" can be used to
359 specify how long the applications should wait for sessiond
360 "registration done" command before proceeding to execute the main
361 program. The default is 3000ms (3 seconds). The timeout value is
362 specified in milliseconds. The value 0 means "don't wait". The value
363 \-1 means "wait forever". Setting this environment variable to 0 is
364 recommended for applications with time constraints on the process
365 startup time.
366 .PP
367
368 .SH "SEE ALSO"
369
370 .PP
371 lttng-gen-tp(1), lttng(1), babeltrace(1), lttng-ust-cyg-profile(3),
372 lttng-sessiond(8)
373 .PP
374 .SH "BUGS"
375
376 .PP
377 No known bugs at this point.
378
379 If you encounter any issues or usability problem, please report it on
380 our mailing list <lttng-dev@lists.lttng.org> to help improve this
381 project.
382 .SH "CREDITS"
383
384 liblttng-ust is distributed under the GNU Lesser General Public License
385 version 2.1. The headers are distributed under the MIT license.
386 .PP
387 See http://lttng.org for more information on the LTTng project.
388 .PP
389 Mailing list for support and development: <lttng-dev@lists.lttng.org>.
390 .PP
391 You can find us on IRC server irc.oftc.net (OFTC) in #lttng.
392 .PP
393 .SH "THANKS"
394
395 Thanks to Ericsson for funding this work, providing real-life use-cases,
396 and testing.
397
398 Special thanks to Michel Dagenais and the DORSAL laboratory at
399 Polytechnique de Montreal for the LTTng journey.
400 .PP
401 .SH "AUTHORS"
402
403 .PP
404 liblttng-ust was originally written by Mathieu Desnoyers, with additional
405 contributions from various other people. It is currently maintained by
406 Mathieu Desnoyers <mathieu.desnoyers@efficios.com>.
407 .PP
This page took 0.038617 seconds and 3 git commands to generate.