X-Git-Url: http://git.liburcu.org/?a=blobdiff_plain;f=doc%2Fman%2Flttng-ust.3.txt;h=2534612a7ecb9ea4d866ea237f80d2437665cb9a;hb=df807054e56e2b476278b1da34de7204e1925452;hp=046e5b458233ed99574894ef7655c485f757fbcf;hpb=8902dadc26f8ed82bb77fc1c7fc4180631a92339;p=lttng-ust.git diff --git a/doc/man/lttng-ust.3.txt b/doc/man/lttng-ust.3.txt index 046e5b45..2534612a 100644 --- a/doc/man/lttng-ust.3.txt +++ b/doc/man/lttng-ust.3.txt @@ -605,9 +605,9 @@ source: Create the tracepoint provider object file: [role="term"] --------------- -cc -c -I. tp.c --------------- +---- +$ cc -c -I. tp.c +---- NOTE: Although an application instrumented with LTTng-UST tracepoints can be compiled with a C++ compiler, tracepoint probes should be @@ -618,9 +618,9 @@ possibly with other object files of your application or with other tracepoint provider object files, as a static library: [role="term"] ---------------- -ar rc tp.a tp.o ---------------- +---- +$ ar rc tp.a tp.o +---- Using a static library does have the advantage of centralising the tracepoint providers objects so they can be shared between multiple @@ -635,9 +635,9 @@ library containing it) and with `liblttng-ust` and `libdl` (`libc` on a BSD system): [role="term"] -------------------------------------- -cc -o app tp.o app.o -llttng-ust -ldl -------------------------------------- +---- +$ cc -o app tp.o app.o -llttng-ust -ldl +---- [[build-dynamic]] @@ -678,16 +678,16 @@ built like it is using the static linking method, but with the nloption:-fpic option: [role="term"] --------------------- -cc -c -fpic -I. tp.c --------------------- +---- +$ cc -c -fpic -I. tp.c +---- It is then linked as a shared library like this: [role="term"] -------------------------------------------------------- -cc -shared -Wl,--no-as-needed -o tp.so tp.o -llttng-ust -------------------------------------------------------- +---- +$ cc -shared -Wl,--no-as-needed -o tp.so tp.o -llttng-ust +---- This tracepoint provider shared object isn't linked with the user application: it must be loaded manually. This is why the application is @@ -695,9 +695,9 @@ built with no mention of this tracepoint provider, but still needs libdl: [role="term"] --------------------------------- -cc -o app app.o tp-define.o -ldl --------------------------------- +---- +$ cc -o app app.o tp-define.o -ldl +---- There are two ways to dynamically load the tracepoint provider shared object: @@ -738,6 +738,12 @@ without a following man:exec(3) family system call. The library application with the `LD_PRELOAD` environment variable (see man:ld.so(8)). +To use `liblttng-ust` with a daemon application which closes file +descriptors that were not opened by it, preload the `liblttng-ust-fd.so` +library before you start the application. Typical use cases include +daemons closing all file descriptors after man:fork(2), and buggy +applications doing ``double-closes''. + Context information ~~~~~~~~~~~~~~~~~~~ @@ -763,12 +769,16 @@ information about event filtering. reverse-lookup the source location that caused the event to be emitted. -+perf:thread:COUNTER+:: +`perf:thread:COUNTER`:: perf counter named 'COUNTER'. Use `lttng add-context --list` to list the available perf counters. + Only available on IA-32 and x86-64 architectures. +`perf:thread:raw:rN:NAME`:: + perf counter with raw ID 'N' and custom name 'NAME'. See + man:lttng-add-context(1) for more details. + `pthread_id`:: POSIX thread identifier. Can be used on architectures where `pthread_t` maps nicely to an `unsigned long` type. @@ -780,11 +790,67 @@ Only available on IA-32 and x86-64 architectures. `vpid`:: Virtual process ID: process ID as seen from the point of view of - the process namespace. + the current man:pid_namespaces(7). `vtid`:: Virtual thread ID: thread ID as seen from the point of view of - the process namespace. + the current man:pid_namespaces(7). + +The following man:namespaces(7) context fields are supported by LTTng-UST: + +`cgroup_ns`:: + Cgroup root directory namespace: inode number of the current + man:cgroup_namespaces(7) in the proc filesystem. + +`ipc_ns`:: + System V IPC, POSIX message queues namespace: inode number of the + current man:ipc_namespaces(7) namespace in the proc filesystem. + +`mnt_ns`:: + Mount points namespace: inode number of the current + man:mount_namespaces(7) in the proc filesystem. + +`net_ns`:: + Network devices, stacks, ports namespace: inode number of the + current man:network_namespaces(7) in the proc filesystem. + +`pid_ns`:: + Process IDs namespace: inode number of the current + man:pid_namespaces(7) in the proc filesystem. + +`user_ns`:: + User and group IDs namespace: inode number of the current + man:user_namespaces(7) in the proc filesystem. + +`uts_ns`:: + Hostname and NIS domain name namespace: inode number of the + current man:uts_namespaces(7) in the proc filesystem. + +The following man:credentials(7) context fields are supported by LTTng-UST: + +`vuid`:: + Virtual real user ID: real user ID as seen from the point of view of + the current man:user_namespaces(7). + +`vgid`:: + Virtual real group ID: real group ID as seen from the point of view of + the current man:user_namespaces(7). + +`veuid`:: + Virtual effective user ID: effective user ID as seen from the point of + view of the current man:user_namespaces(7). + +`vegid`:: + Virtual effective group ID: effective group ID as seen from the point of + view of the current man:user_namespaces(7). + +`vsuid`:: + Virtual saved set-user ID: saved set-user ID as seen from the point of + view of the current man:user_namespaces(7). + +`vsgid`:: + Virtual saved set-group ID: saved set-group ID as seen from the point of + view of the current man:user_namespaces(7). [[state-dump]] @@ -796,7 +862,9 @@ build IDs, and their debug link information are emitted as events by the tracer. The following LTTng-UST state dump events exist and must be enabled -to record application state dumps. +to record application state dumps. Note that, during the state dump +phase, LTTng-UST can also emit _shared library load/unload_ events +(see <> below). `lttng_ust_statedump:start`:: Emitted when the state dump begins. @@ -821,16 +889,26 @@ Fields: |Field name |Description |`baddr` -|Base address of loaded executable +|Base address of loaded executable. |`memsz` -|Size of loaded executable in memory +|Size of loaded executable in memory. |`path` -|Path to loaded executable file +|Path to loaded executable file. |`is_pic` -|Whether the executable is position-independent code +|Whether or not the executable is position-independent code. + +|`has_build_id` +|Whether or not the executable has a build ID. If this field is 1, you +can expect that an `lttng_ust_statedump:build_id` event record follows +this one (not necessarily immediately after). + +|`has_debug_link` +|Whether or not the executable has debug link information. If this field +is 1, you can expect that an `lttng_ust_statedump:debug_link` event +record follows this one (not necessarily immediately after). |=== `lttng_ust_statedump:build_id`:: @@ -846,10 +924,10 @@ Fields: |Field name |Description |`baddr` -|Base address of loaded library +|Base address of loaded library. |`build_id` -|Build ID +|Build ID. |=== `lttng_ust_statedump:debug_link`:: @@ -865,21 +943,142 @@ Fields: |Field name |Description |`baddr` -|Base address of loaded library +|Base address of loaded library. + +|`crc` +|Debug link file's CRC. + +|`filename` +|Debug link file name. +|=== + + +[[ust-lib]] +Shared library load/unload tracking +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The <> and the LTTng-UST helper library +to instrument the dynamic linker (see man:liblttng-ust-dl(3)) can emit +**shared library load/unload tracking** events. + +The following shared library load/unload tracking events exist and must +be enabled to track the loading and unloading of shared libraries: + +`lttng_ust_lib:load`:: + Emitted when a shared library (shared object) is loaded. ++ +Fields: ++ +[options="header"] +|=== +|Field name |Description + +|`baddr` +|Base address of loaded library. + +|`memsz` +|Size of loaded library in memory. + +|`path` +|Path to loaded library file. + +|`has_build_id` +|Whether or not the library has a build ID. If this field is 1, you +can expect that an `lttng_ust_lib:build_id` event record follows +this one (not necessarily immediately after). + +|`has_debug_link` +|Whether or not the library has debug link information. If this field +is 1, you can expect that an `lttng_ust_lib:debug_link` event +record follows this one (not necessarily immediately after). +|=== + +`lttng_ust_lib:unload`:: + Emitted when a shared library (shared object) is unloaded. ++ +Fields: ++ +[options="header"] +|=== +|Field name |Description + +|`baddr` +|Base address of unloaded library. +|=== + +`lttng_ust_lib:build_id`:: + Emitted when a build ID is found in a loaded shared library (shared + object). See + https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html[Debugging Information in Separate Files] + for more information about build IDs. ++ +Fields: ++ +[options="header"] +|=== +|Field name |Description + +|`baddr` +|Base address of loaded library. + +|`build_id` +|Build ID. +|=== + +`lttng_ust_lib:debug_link`:: + Emitted when debug link information is found in a loaded + shared library (shared object). See + https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html[Debugging Information in Separate Files] + for more information about debug links. ++ +Fields: ++ +[options="header"] +|=== +|Field name |Description + +|`baddr` +|Base address of loaded library. |`crc` -|Debug link file's CRC +|Debug link file's CRC. |`filename` -|Debug link file name +|Debug link file name. |=== +Detect if LTTng-UST is loaded +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +To detect if `liblttng-ust` is loaded from an application: + +. Define the `lttng_ust_loaded` weak symbol globally: ++ +------------------------------------------------------------------------ +int lttng_ust_loaded __attribute__((weak)); +------------------------------------------------------------------------ ++ +This weak symbol is set by the constructor of `liblttng-ust`. + +. Test `lttng_ust_loaded` where needed: ++ +------------------------------------------------------------------------ +/* ... */ + +if (lttng_ust_loaded) { + /* LTTng-UST is loaded */ +} else { + /* LTTng-UST is NOT loaded */ +} + +/* ... */ +------------------------------------------------------------------------ + + [[example]] EXAMPLE ------- NOTE: A few examples are available in the -https://github.com/lttng/lttng-ust/tree/master/doc/examples[`doc/examples`] +https://github.com/lttng/lttng-ust/tree/v{lttng_version}/doc/examples[`doc/examples`] directory of LTTng-UST's source tree. This example shows all the features documented in the previous @@ -890,44 +1089,44 @@ You can compile the source files and link them together statically like this: [role="term"] -------------------------------------- -cc -c -I. tp.c -cc -c app.c -cc -o app tp.o app.o -llttng-ust -ldl -------------------------------------- +---- +$ cc -c -I. tp.c +$ cc -c app.c +$ cc -o app tp.o app.o -llttng-ust -ldl +---- Using the man:lttng(1) tool, create an LTTng tracing session, enable all the events of this tracepoint provider, and start tracing: [role="term"] ----------------------------------------------- -lttng create my-session -lttng enable-event --userspace 'my_provider:*' -lttng start ----------------------------------------------- +---- +$ lttng create my-session +$ lttng enable-event --userspace 'my_provider:*' +$ lttng start +---- You may also enable specific events: [role="term"] ----------------------------------------------------------- -lttng enable-event --userspace my_provider:big_event -lttng enable-event --userspace my_provider:event_instance2 ----------------------------------------------------------- +---- +$ lttng enable-event --userspace my_provider:big_event +$ lttng enable-event --userspace my_provider:event_instance2 +---- Run the application: [role="term"] --------------------- -./app some arguments --------------------- +---- +$ ./app some arguments +---- Stop the current tracing session and inspect the recorded events: [role="term"] ----------- -lttng stop -lttng view ----------- +---- +$ lttng stop +$ lttng view +---- Tracepoint provider header file @@ -1149,44 +1348,38 @@ LTTng session and consumer daemons (part of the LTTng-tools project) are located in a specific directory under `$LTTNG_HOME` (or `$HOME` if `$LTTNG_HOME` is not set). -`LTTNG_UST_BLOCKING_RETRY_TIMEOUT`:: - Maximum duration (milliseconds) to retry event tracing when - there's no space left for the event record in the sub-buffer. +`LTTNG_UST_ALLOW_BLOCKING`:: + If set, allow the application to retry event tracing when there's + no space left for the event record in the sub-buffer, therefore + effectively blocking the application until space is made available + or the configured timeout is reached. + --- -`0` (default):: - Never block the application. - -Positive value:: - Block the application for the specified number of milliseconds. If - there's no space left after this duration, discard the event - record. - -Negative value:: - Block the application until there's space left for the event record. --- +To allow an application to block during tracing, you also need to +specify a blocking timeout when you create a channel with the +nloption:--blocking-timeout option of the man:lttng-enable-channel(1) +command. + This option can be useful in workloads generating very large trace data throughput, where blocking the application is an acceptable trade-off to prevent discarding event records. + -WARNING: Setting this environment variable to a non-zero value may -significantly affect application timings. +WARNING: Setting this environment variable may significantly +affect application timings. `LTTNG_UST_CLOCK_PLUGIN`:: Path to the shared object which acts as the clock override plugin. An example of such a plugin can be found in the LTTng-UST documentation under - https://github.com/lttng/lttng-ust/tree/master/doc/examples/clock-override[`examples/clock-override`]. + https://github.com/lttng/lttng-ust/tree/v{lttng_version}/doc/examples/clock-override[`examples/clock-override`]. `LTTNG_UST_DEBUG`:: - Activates `liblttng-ust`'s debug and error output if set to `1`. + If set, enable `liblttng-ust`'s debug and error output. `LTTNG_UST_GETCPU_PLUGIN`:: Path to the shared object which acts as the `getcpu()` override plugin. An example of such a plugin can be found in the LTTng-UST documentation under - https://github.com/lttng/lttng-ust/tree/master/doc/examples/getcpu-override[`examples/getcpu-override`]. + https://github.com/lttng/lttng-ust/tree/v{lttng_version}/doc/examples/getcpu-override[`examples/getcpu-override`]. `LTTNG_UST_REGISTER_TIMEOUT`:: Waiting time for the _registration done_ session daemon command @@ -1198,28 +1391,9 @@ with time constraints on the process startup time. + Default: {lttng_ust_register_timeout}. -`LTTNG_UST_BLOCKING_RETRY_TIMEOUT`:: - Maximum time during which event tracing retry is attempted on buffer - full condition (millliseconds). Setting this environment to non-zero - value effectively blocks the application on buffer full condition. - Setting this environment variable to non-zero values may - significantly affect application timings. Setting this to a negative - value may block the application indefinitely if there is no consumer - emptying the ring buffer. The delay between retry attempts is the - minimum between the specified timeout value and 100ms. This option - can be useful in workloads generating very large trace data - throughput, where blocking the application is an acceptable - trade-off to not discard events. _Use with caution_. -+ -The value `0` means _do not retry_. The value `-1` means _retry forever_. -Value > `0` means a maximum timeout of the given value. -+ -Default: {lttng_ust_blocking_retry_timeout}. - `LTTNG_UST_WITHOUT_BADDR_STATEDUMP`:: - Prevents `liblttng-ust` from performing a base address state dump - (see the <> section above) if - set to `1`. + If set, prevents `liblttng-ust` from performing a base address state + dump (see the <> section above). include::common-footer.txt[]