[lkml]   [2008]   [Jan]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
Subject[patch 2/2] x86, ptrace, man: corresponding man pages
Man pages for the ptrace bts API.

Signed-off-by: Markus Metzger <>

Index: man/man2/ptrace.2
--- man.orig/man2/ptrace.2 2008-01-08 11:21:38.%N +0100
+++ man/man2/ptrace.2 2008-01-08 11:22:38.%N +0100
@@ -40,6 +40,9 @@
.\" (Thanks to Blaisorblade, Daniel Jacobowitz and others who helped.)
+.\" Modified Nov 2007, Markus Metzger <>
+.\" Added PTRACE_BTS_* commands
.TH PTRACE 2 2007-11-15 "Linux" "Linux Programmer's Manual"
ptrace \- process trace
@@ -378,6 +381,134 @@
detached in this way regardless of which method was used to initiate
(\fIaddr\fP is ignored.)
+The following ptrace commands provide access to the hardware's last
+branch recording. They may not be available on all architectures.
+Last branch recording stores an execution trace of the traced
+process. For every (conditional) control flow change, the source and
+destination address are stored. On some architectures, control flow
+changes inside the kernel are recorded, as well. On later
+architectures, these are automatically filtered out.
+The buffer (called Branch Trace Store) can be configured to be either
+circular, or to send a signal to the traced task when it is about to
+overflow. Not all methods may be available on all architectures.
+The buffer can be accessed in two ways matching the above
+configurations: either as an array of BTS records from newest
+record to older records, one record at a time; or all records at once,
+from oldest to newest.
+The former is mostly used for circular buffers to capture a tail of
+the execution trace (e.g. for debugging); the latter is mostly used to
+collect a continuous trace (e.g. for profiling) where the user drains
+the hardware buffer into a larger private buffer or into a file.
+In addition to branches, timestamps (in jiffies) may optionally be
+recorded when the traced process arrives and departs,
+respectively. This information can be used to obtain a qualitative
+execution order, if more than one process is traced.
+A BTS record is defined as:
+enum ptrace_bts_qualifier {
+struct ptrace_bts_record {
+ u64 qualifier;
+ union {
+ struct {
+ u64 from_ip;
+ u64 to_ip;
+ } lbr;
+ u64 timestamp;
+ } variant;
+For configuring last branch recording and for querying its status, the
+following struct is used:
+struct ptrace_bts_config {
+ u32 size;
+ u32 flags;
+ u32 signal;
+ u32 bts_size;
+\fISize\fP is either the requested or the actual size of the kernel
+BTS buffer in bytes.
+\fIFlags\fP is a bitmask of options, which are specified by the
+following flags:
+Collect branch trace records
+Collect scheduling timing information
+Send \fIsignal\fP to the traced task in case of a buffer overflow
+Reduce the requested buffer size if it is bigger than the available
+buffer size.
+\fISignal\fP is the signal to send to the traced task in case of a
+buffer overflow.
+\fIBts_size\fP is the actual size of the \fIptrace_bts_record\fP
+structure in bytes. It is ignored for configuration purposes.
+Configure last branch recording. \fIaddr\fP points to a
+\fIptrace_bts_config\fP structure (see above); \fIdata\fP specifies
+the size of that structure.
+Returns the number of bytes read.
+Writes the actual configuration into a \fIptrace_bts_config\fP
+structure pointed to by \fIaddr\fP. The caller is responsible for
+allocating memory at \fIaddr\fP to hold a \fIptrace_bts_config\fP
+structure. \fIData\fP specifies the size of that structure.
+Returns the number of bytes written.
+Returns the number of BTS records available for draining. For a
+circular buffer, this number is meaningless.
+(\fIaddr\fP and \fIdata\fP are ignored.)
+Reads a single BTS record at index \fIdata\fP into \fIaddr\fP. The
+caller is responsible for allocating memory at \fIaddr\fP to hold one
+\fIptrace_bts_record\fP structure.
+The bigger the index, the older the record; the latest record can
+always be found at index 0.
+Returns the number of bytes written.
+Clears the BTS buffer. This command can be used after a manual
+draining using PTRACE_BTS_GET commands.
+(\fIaddr\fP and \fIdata\fP are ignored.)
+Reads all available BTS records into the buffer pointed to by
+\fIaddr\fP and clears the buffer. Records are read from oldest to
+newest. Returns the number of BTS records drained. The caller
+is responsible for allocating enough memory to hold an array of
+PTRACE_BTS_SIZE \fIptrace_bts_record\fP structures. \fIData\fP
+specifies the size of that buffer.
On success,
@@ -432,6 +563,16 @@
The specified process does not exist, or is not currently being traced
by the caller, or is not stopped (for requests that require that).
+The operation is not supported on this architecture.
+Not enough memory to allocate the BTS buffer.
+An attempt to access BTS information has been made without allocating
+a BTS buffer first.
SVr4, 4.3BSD
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

 \ /
  Last update: 2008-01-08 11:55    [W:0.033 / U:7.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site