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
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
(`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]]
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
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:
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
there's no space left for the event record in the sub-buffer.
+
--
-`0` (default)::
+`0`::
Never block the application.
Positive value::
Block the application until there's space left for the event record.
--
+
+Default: {lttng_ust_blocking_retry_timeout}.
++
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.
+
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 <<state-dump,LTTng-UST state dump>> section above) if