Trace file contents
A trace file essentially consists in
A header with general information about the trace generation context (name of the binary executable passed to gnatcov run,
--tag
argument value, production date & time, …), followed byThe machine execution trace entries (roughly, one per execution basic block, with information on the branch decision at the end)
gnatcov offers a dump-trace
option to display the contents of trace
files passed as arguments, displaying tags passed to gnatcov run amongst other
things. For example:
gnatcov dump-trace test_divmod2.trace
Tag : DATE_TIME (Date)
Len : 8
Data : dc 07 02 15 08 00 25 00
2012-02-21 08:00:37
Tag : EXEC_FILE_NAME
Len : 16
Data : obj/test_divmod2
Tag : USER_DATA (User_Tag)
Len : 10
Data : sample tag
Traces:
fffffffc-fffffffb ?: 20 ---- fault
fffffffc-ffffffff ?: 11 ---t block
fff0067c-fff006b3 ?: 11 ---t block
fff006bc-fff006bf ?: 12 --t- block
[...]
Prior to the execution traces per-se (list of executed instruction blocks past
the Traces:
label), we see a few information entries aimed at helping
GNATcoverage and users on various accounts. Each entry has a tag identifying it’s
kind, then some associated data dependent on the kind. Our example above
features the following information entries:
DATE_TIME
:The trace production time stamp, always 8 bytes long.
EXEC_FILE_NAME
:Path to the binary program that was executed to produce the trace. This path can be exactly the one that was passed to gnatcov run or a derived path, for instance if gnatcov run had to add an extension to find the actual file (see Target specific points of note with Binary traces). gnatcov coverage uses this path to find the program file again at analysis time, to find which machine code corresponds to which address for example.
USER_DATA
:User string tag for this trace, when one was passed with
-T
to gnatcov run.
The precise structure is described in the qemu_traces.ads
unit of the
gnatcov sources.