This file is indexed.

/usr/share/doc/libgoogle-perftools-dev/cpuprofile-fileformat.html is in libgoogle-perftools-dev 2.1-2ubuntu1.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML>

<HEAD>
  <link rel="stylesheet" href="designstyle.css">
  <title>Google CPU Profiler Binary Data File Format</title>
</HEAD>

<BODY>

<h1>Google CPU Profiler Binary Data File Format</h1>

<p align=right>
  <i>Last modified
    <script type=text/javascript>
    var lm = new Date(document.lastModified);
    document.write(lm.toDateString());
  </script></i>
</p>

<p>This file documents the binary data file format produced by the
Google CPU Profiler.  For information about using the CPU Profiler,
see <a href="cpuprofile.html">its user guide</a>.

<p>The profiler source code, which generates files using this format, is at
<code>src/profiler.cc</code></a>.


<h2>CPU Profile Data File Structure</h2>

<p>CPU profile data files each consist of four parts, in order:

<ul>
  <li> Binary header
  <li> Binary profile records
  <li> Binary trailer
  <li> Text list of mapped objects
</ul>

<p>The binary data is expressed in terms of "slots."  These are words
large enough to hold the program's pointer type, i.e., for 32-bit
programs they are 4 bytes in size, and for 64-bit programs they are 8
bytes.  They are stored in the profile data file in the native byte
order (i.e., little-endian for x86 and x86_64).


<h2>Binary Header</h2>

<p>The binary header format is show below.  Values written by the
profiler, along with requirements currently enforced by the analysis
tools, are shown in parentheses.

<p>
<table summary="Header Format"
       frame="box" rules="sides" cellpadding="5" width="50%">
  <tr>
    <th width="30%">slot</th>
    <th width="70%">data</th>
  </tr>

  <tr>
    <td>0</td>
    <td>header count (0; must be 0)</td>
  </tr>

  <tr>
    <td>1</td>
    <td>header slots after this one (3; must be &gt;= 3)</td>
  </tr>

  <tr>
    <td>2</td>
    <td>format version (0; must be 0)</td>
  </tr>

  <tr>
    <td>3</td>
    <td>sampling period, in microseconds</td>
  </tr>

  <tr>
    <td>4</td>
    <td>padding (0)</td>
  </tr>
</table>

<p>The headers currently generated for 32-bit and 64-bit little-endian
(x86 and x86_64) profiles are shown below, for comparison.

<p>
<table summary="Header Example" frame="box" rules="sides" cellpadding="5">
  <tr>
    <th></th>
    <th>hdr count</th>
    <th>hdr words</th>
    <th>version</th>
    <th>sampling period</th>
    <th>pad</th>
  </tr>
  <tr>
    <td>32-bit or 64-bit (slots)</td>
    <td>0</td>
    <td>3</td>
    <td>0</td>
    <td>10000</td>
    <td>0</td>
  </tr>
  <tr>
    <td>32-bit (4-byte words in file)</td>
    <td><tt>0x00000</tt></td>
    <td><tt>0x00003</tt></td>
    <td><tt>0x00000</tt></td>
    <td><tt>0x02710</tt></td>
    <td><tt>0x00000</tt></td>
  </tr>
  <tr>
    <td>64-bit LE (4-byte words in file)</td>
    <td><tt>0x00000&nbsp;0x00000</tt></td>
    <td><tt>0x00003&nbsp;0x00000</tt></td>
    <td><tt>0x00000&nbsp;0x00000</tt></td>
    <td><tt>0x02710&nbsp;0x00000</tt></td>
    <td><tt>0x00000&nbsp;0x00000</tt></td>
  </tr>
</table>

<p>The contents are shown in terms of slots, and in terms of 4-byte
words in the profile data file.  The slot contents for 32-bit and
64-bit headers are identical.  For 32-bit profiles, the 4-byte word
view matches the slot view.  For 64-bit profiles, each (8-byte) slot
is shown as two 4-byte words, ordered as they would appear in the
file.

<p>The profiling tools examine the contents of the file and use the
expected locations and values of the header words field to detect
whether the file is 32-bit or 64-bit.


<h2>Binary Profile Records</h2>

<p>The binary profile record format is shown below.

<p>
<table summary="Profile Record Format"
       frame="box" rules="sides" cellpadding="5" width="50%">
  <tr>
    <th width="30%">slot</th>
    <th width="70%">data</th>
  </tr>

  <tr>
    <td>0</td>
    <td>sample count, must be &gt;= 1</td>
  </tr>

  <tr>
    <td>1</td>
    <td>number of call chain PCs (num_pcs), must be &gt;= 1</td>
  </tr>

  <tr>
    <td>2 .. (num_pcs + 1)</td>
    <td>call chain PCs, most-recently-called function first.
  </tr>
</table>

<p>The total length of a given record is 2 + num_pcs.

<p>Note that multiple profile records can be emitted by the profiler
having an identical call chain.  In that case, analysis tools should
sum the counts of all records having identical call chains.

<p><b>Note:</b> Some profile analysis tools terminate if they see
<em>any</em> profile record with a call chain with its first entry
having the address 0.  (This is similar to the binary trailer.)

<h3>Example</h3>

This example shows the slots contained in a sample profile record.

<p>
<table summary="Profile Record Example"
       frame="box" rules="sides" cellpadding="5">
  <tr>
    <td>5</td>
    <td>3</td>
    <td>0xa0000</td>
    <td>0xc0000</td>
    <td>0xe0000</td>
  </tr>
</table>

<p>In this example, 5 ticks were received at PC 0xa0000, whose
function had been called by the function containing 0xc0000, which had
been called from the function containing 0xe0000.


<h2>Binary Trailer</h2>

<p>The binary trailer consists of three slots of data with fixed
values, shown below.

<p>
<table summary="Trailer Format"
       frame="box" rules="sides" cellpadding="5" width="50%">
  <tr>
    <th width="30%">slot</th>
    <th width="70%">value</th>
  </tr>

  <tr>
    <td>0</td>
    <td>0</td>
  </tr>

  <tr>
    <td>1</td>
    <td>1</td>
  </tr>

  <tr>
    <td>2</td>
    <td>0</td>
  </tr>
</table>

<p>Note that this is the same data that would contained in a profile
record with sample count = 0, num_pcs = 1, and a one-element call
chain containing the address 0.


<h2>Text List of Mapped Objects</h2>

<p>The binary data in the file is followed immediately by a list of
mapped objects.  This list consists of lines of text separated by
newline characters.

<p>Each line is one of the following types:

<ul>
  <li>Build specifier, starting with "<tt>build=</tt>".  For example:
    <pre>  build=/path/to/binary</pre>
    Leading spaces on the line are ignored.

  <li>Mapping line from ProcMapsIterator::FormatLine.  For example:
    <pre>  40000000-40015000 r-xp 00000000 03:01 12845071   /lib/ld-2.3.2.so</pre>
    The first address must start at the beginning of the line.
</ul>

<p>Unrecognized lines should be ignored by analysis tools.

<p>When processing the paths see in mapping lines, occurrences of
<tt>$build</tt> followed by a non-word character (i.e., characters
other than underscore or alphanumeric characters), should be replaced
by the path given on the last build specifier line.

<hr>
<address>Chris Demetriou<br>
<!-- Created: Mon Aug 27 12:18:26 PDT 2007 -->
<!-- hhmts start -->
Last modified: Mon Aug 27 12:18:26 PDT 2007  (cgd)
<!-- hhmts end -->
</address>
</BODY>
</HTML>