+
See man:lttng-status(1).
-** New `lttng metadata regenerate` command to regenerate the metadata
- file of an LTTng trace at any moment. This command is meant to be
- used to resample the wall time following a major
+** New `lttng metadata regenerate` command to
+ <<metadata-regenerate,regenerate the metadata file of an LTTng
+ trace>> at any moment. This command is meant to be used to resample
+ the wall time following a major
https://en.wikipedia.org/wiki/Network_Time_Protocol[NTP] correction
so that a system which boots with an incorrect wall time can be
traced before its wall time is NTP-corrected.
other Buildroot releases.
|OpenEmbedded and Yocto
-|<<oe-yocto,`openembedded-core` layer since 3{nbsp}September 2016>>
-|LTTng{nbsp}2.7 for OpenEmbedded from 1{nbsp}December 2016 until
-3{nbsp}September 2016.
-
-<<building-from-source,Build LTTng{nbsp}{revision} from source>> for
+|<<oe-yocto,Yocto Project{nbsp}2.2 _Morty_>> (`openembedded-core` layer)
+|<<building-from-source,Build LTTng{nbsp}{revision} from source>> for
other OpenEmbedded releases.
|====
LTTng{nbsp}{revision} recipes are available in the
http://layers.openembedded.org/layerindex/branch/master/layer/openembedded-core/[`openembedded-core`]
-layer of OpenEmbedded since 3{nbsp}September 2016
-under the following names:
+layer for Yocto Project{nbsp}2.2 _Morty_ under the following names:
* `lttng-tools`
* `lttng-modules`
Once you <<tpp-header,create a tracepoint provider header file>>, you
can use the `tracepoint()` macro in your application's
source code to insert the tracepoints that this header
-<<defining-tracepoints,defined>> defines.
+<<defining-tracepoints,defines>>.
The `tracepoint()` macro takes at least two parameters: the tracepoint
provider name and the tracepoint name. The corresponding tracepoint
`libemon.so`::
User library shared object file.
-The red star indicates that this object file is instrumented
-(contains code which uses the `tracepoint()` macro). The spring
-symbol between the application and a library means the application is
-linked with the library at build time.
+We use the following symbols in the diagrams of table below:
+
+[role="img-100"]
+.Symbols used in the build scenario diagrams.
+image::ust-sit-symbols.png[]
We assume that path:{.} is part of the env:LD_LIBRARY_PATH environment
variable in the following instructions.
entry is enough to create a call graph, since an event record always
contains the ID of the CPU that generated it.
+
-You can use a tool like
-https://sourceware.org/binutils/docs/binutils/addr2line.html[cmd:addr2line]
-to convert function addresses back to source file names and
-line numbers.
+You can use a tool like man:addr2line(1) to convert function addresses
+back to source file names and line numbers.
* **path:{liblttng-ust-cyg-profile.so}** is a more robust variant
which also works in use cases where event records might get discarded or