OpenE2K/binutils-gdb
12
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

* gdb.texinfo (Trace File Format): Move node later.

Browse Source
This commit is contained in:
Tom Tromey 2011-04-20 13:22:50 +00:00
parent 8ad17b3a2c
commit 05c8c3f5b0
2 changed files with 57 additions and 53 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
gdb/doc/ChangeLog
View File

@ -1,3 +1,7 @@
2011-04-20 Tom Tromey <tromey@redhat.com>
* gdb.texinfo (Trace File Format): Move node later.
2011-04-19 Tom Tromey <tromey@redhat.com>
* gdbint.texinfo (Register Information Functions): Remove

106
gdb/doc/gdb.texinfo
View File

@ -36179,59 +36179,6 @@ The formal DTD for the traceframe info format is given below:
@include agentexpr.texi
@node Trace File Format
@appendix Trace File Format
@cindex trace file format
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 @code{\x7fTRACE0\n}. The first byte is
@code{0x7f} so as to indicate that the file contains binary data,
while the @code{0} is a version number that may have different values
in the future.
The description section consists of multiple lines of @sc{ascii} text
separated by newline characters (@code{0xa}). The lines may include a
variety of optional descriptive or context-setting information, such
as tracepoint definitions or register set size. @value{GDBN} will
ignore any line that it does not recognize. An empty line marks the end
of this section.
@c FIXME add some specific types of data
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.
@c FIXME bi-arch may require endianness/arch info in description section
@table @code
@item R @var{bytes}
Register block. The number and ordering of bytes matches that of a
@code{g} packet in the remote protocol. Note that these are the
actual bytes, in target order and @value{GDBN} register order, not a
hexadecimal encoding.
@item M @var{address} @var{length} @var{bytes}...
Memory block. This is a contiguous block of memory, at the 8-byte
address @var{address}, with a 2-byte length @var{length}, followed by
@var{length} bytes.
@item V @var{number} @var{value}
Trace state variable block. This records the 8-byte signed value
@var{value} of trace state variable numbered @var{number}.
@end table
Future enhancements of the trace file format may include additional types
of blocks.
@node Target Descriptions
@appendix Target Descriptions
@cindex target descriptions
@ -36909,6 +36856,59 @@ should contain a comma-separated list of cores that this process
is running on. Target may provide additional columns,
which @value{GDBN} currently ignores.
@node Trace File Format
@appendix Trace File Format
@cindex trace file format
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 @code{\x7fTRACE0\n}. The first byte is
@code{0x7f} so as to indicate that the file contains binary data,
while the @code{0} is a version number that may have different values
in the future.
The description section consists of multiple lines of @sc{ascii} text
separated by newline characters (@code{0xa}). The lines may include a
variety of optional descriptive or context-setting information, such
as tracepoint definitions or register set size. @value{GDBN} will
ignore any line that it does not recognize. An empty line marks the end
of this section.
@c FIXME add some specific types of data
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.
@c FIXME bi-arch may require endianness/arch info in description section
@table @code
@item R @var{bytes}
Register block. The number and ordering of bytes matches that of a
@code{g} packet in the remote protocol. Note that these are the
actual bytes, in target order and @value{GDBN} register order, not a
hexadecimal encoding.
@item M @var{address} @var{length} @var{bytes}...
Memory block. This is a contiguous block of memory, at the 8-byte
address @var{address}, with a 2-byte length @var{length}, followed by
@var{length} bytes.
@item V @var{number} @var{value}
Trace state variable block. This records the 8-byte signed value
@var{value} of trace state variable numbered @var{number}.
@end table
Future enhancements of the trace file format may include additional types
of blocks.
@include gpl.texi
@node GNU Free Documentation License