The trace file comes in three parts: a header, a textual description section, and a trace frame section with binary data.
The header has the form
\x7fTRACE0\n. The first byte is
0x7f so as to indicate that the file contains binary data,
0 is a version number that may have different values
in the future.
The description section consists of multiple lines of ascii text
separated by newline characters (
0xa). The lines may include a
variety of optional descriptive or context-setting information, such
as tracepoint definitions or register set size. gdb will
ignore any line that it does not recognize. An empty line marks the end
of this section.
gpacket payload in the remote protocol. size is an ascii decimal number. There should be only one such line in a single trace file.
qTStatusremote packet reply. There should be only one such line in a single trace file.
qTsPremote packet reply payload. A single tracepoint may take multiple lines of definition, corresponding to the multiple reply packets.
qTsVremote packet reply payload. A single variable may take multiple lines of definition, corresponding to the multiple reply packets.
featurespayload, and corresponds to the main
target.xmlfile. Includes are not allowed.
The trace frame section consists of a number of consecutive frames. Each frame begins with a two-byte tracepoint number, followed by a four-byte size giving the amount of data in the frame. The data in the frame consists of a number of blocks, each introduced by a character indicating its type (at least register, memory, and trace state variable). The data in this section is raw binary, not a hexadecimal or other encoding; its endianness matches the target's endianness.
gpacket in the remote protocol. Note that these are the actual bytes, in target order, not a hexadecimal encoding.
Maddress length bytes
Future enhancements of the trace file format may include additional types of blocks.