cg-tech-docs.html

memory checking tool 源代码valgrind-3.2.1.tar.gz 这是英文使用手册

|(uninit)|      (padding)   (1 byte)
|i_addr2 |      instr_addr  (4 bytes)
|0       |      I.a         (8 bytes)
|0       |      I.m1        (8 bytes)
|0       |      I.m2        (8 bytes)
|0       |      D.a         (8 bytes)
|0       |      D.m1        (8 bytes)
|0       |      D.m2        (8 bytes)</pre>
<p>(Note that this step is not performed if a basic block is
re-translated; see <a href="cg-tech-docs.html#cg-tech-docs.retranslations">Handling basic block retranslations</a> for
more information.)</p>
<p>GCC inserts padding before the
<code class="computeroutput">instr_size</code> field so that it is
word aligned.</p>
<p>The instrumentation added to call the cache simulation
function looks like this (instrumentation is indented to
distinguish it from the original UCode):</p>
<pre class="programlisting">
MOVL      $0x0, t20
PUTL      t20, %EAX
  PUSHL     %eax
  PUSHL     %ecx
  PUSHL     %edx
  MOVL      $0x4091F8A4, t46  # address of 1st CC
  PUSHL     t46
  CALLMo    $0x12             # second cachesim function
  CLEARo    $0x4
  POPL      %edx
  POPL      %ecx
  POPL      %eax
INCEIPo   $5

LEA1L     -4(t4), t14
MOVL      $0x99, t18
  MOVL      t14, t42
STL       t18, (t14)
  PUSHL     %eax
  PUSHL     %ecx
  PUSHL     %edx
  PUSHL     t42
  MOVL      $0x4091F8C4, t44  # address of 2nd CC
  PUSHL     t44
  CALLMo    $0x13             # second cachesim function
  CLEARo    $0x8
  POPL      %edx
  POPL      %ecx
  POPL      %eax
INCEIPo   $7</pre>
<p>Consider the first instruction's UCode.  Each call is
surrounded by three <code class="computeroutput">PUSHL</code> and
<code class="computeroutput">POPL</code> instructions to save and
restore the caller-save registers.  Then the address of the
instruction's cost centre is pushed onto the stack, to be the
first argument to the cache simulation function.  The address is
known at this point because we are doing a simultaneous pass
through the cost centre array.  This means the cost centre lookup
for each instruction is almost free (just the cost of pushing an
argument for a function call).  Then the call to the cache
simulation function for non-memory-reference instructions is made
(note that the <code class="computeroutput">CALLMo</code>
UInstruction takes an offset into a table of predefined
functions; it is not an absolute address), and the single
argument is <code class="computeroutput">CLEAR</code>ed from the
stack.</p>
<p>The second instruction's UCode is similar.  The only
difference is that, as mentioned before, we have to pass the
address of the data item referenced to the cache simulation
function too.  This explains the <code class="computeroutput">MOVL t14,
t42</code> and <code class="computeroutput">PUSHL
t42</code> UInstructions.  (Note that the seemingly
redundant <code class="computeroutput">MOV</code>ing will probably
be optimised away during register allocation.)</p>
<p>Note that instead of storing unchanging information about
each instruction (instruction size, data size, etc) in its cost
centre, we could have passed in these arguments to the simulation
function.  But this would slow the calls down (two or three extra
arguments pushed onto the stack).  Also it would bloat the UCode
instrumentation by amounts similar to the space required for them
in the cost centre; bloated UCode would also fill the translation
cache more quickly, requiring more translations for large
programs and slowing them down more.</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="cg-tech-docs.retranslations"></a>2.5.燞andling basic block retranslations</h2></div></div></div>
<p>The above description ignores one complication.  Valgrind
has a limited size cache for basic block translations; if it
fills up, old translations are discarded.  If a discarded basic
block is executed again, it must be re-translated.</p>
<p>However, we can't use this approach for profiling -- we
can't throw away cost centres for instructions in the middle of
execution!  So when a basic block is translated, we first look
for its cost centre array in the hash table.  If there is no cost
centre array, it must be the first translation, so we proceed as
described above.  But if there is a cost centre array already, it
must be a retranslation.  In this case, we skip the cost centre
allocation and initialisation steps, but still do the UCode
instrumentation step.</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="cg-tech-docs.cachesim"></a>2.6.燭he cache simulation</h2></div></div></div>
<p>The cache simulation is fairly straightforward.  It just
tracks which memory blocks are in the cache at the moment (it
doesn't track the contents, since that is irrelevant).</p>
<p>The interface to the simulation is quite clean.  The
functions called from the UCode contain calls to the simulation
functions in the files
<code class="filename">vg_cachesim_{I1,D1,L2}.c</code>; these calls are
inlined so that only one function call is done per simulated x86
instruction.  The file <code class="filename">vg_cachesim.c</code> simply
<code class="computeroutput">#include</code>s the three files
containing the simulation, which makes plugging in new cache
simulations is very easy -- you just replace the three files and
recompile.</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="cg-tech-docs.output"></a>2.7.燨utput</h2></div></div></div>
<p>Output is fairly straightforward, basically printing the
cost centre for every instruction, grouped by files and
functions.  Total counts (eg. total cache accesses, total L1
misses) are calculated when traversing this structure rather than
during execution, to save time; the cache simulation functions
are called so often that even one or two extra adds can make a
sizeable difference.</p>
<p>Input file has the following format:</p>
<pre class="programlisting">
file         ::= desc_line* cmd_line events_line data_line+ summary_line
desc_line    ::= "desc:" ws? non_nl_string
cmd_line     ::= "cmd:" ws? cmd
events_line  ::= "events:" ws? (event ws)+
data_line    ::= file_line | fn_line | count_line
file_line    ::= ("fl=" | "fi=" | "fe=") filename
fn_line      ::= "fn=" fn_name
count_line   ::= line_num ws? (count ws)+
summary_line ::= "summary:" ws? (count ws)+
count        ::= num | "."</pre>
<p>Where:</p>
<div class="itemizedlist"><ul type="disc">
<li><p><code class="computeroutput">non_nl_string</code> is any
    string not containing a newline.</p></li>
<li><p><code class="computeroutput">cmd</code> is a command line
    invocation.</p></li>
<li><p><code class="computeroutput">filename</code> and
    <code class="computeroutput">fn_name</code> can be anything.</p></li>
<li><p><code class="computeroutput">num</code> and
    <code class="computeroutput">line_num</code> are decimal
    numbers.</p></li>
<li><p><code class="computeroutput">ws</code> is whitespace.</p></li>
<li><p><code class="computeroutput">nl</code> is a newline.</p></li>
</ul></div>
<p>The contents of the "desc:" lines is printed out at the top
of the summary.  This is a generic way of providing simulation
specific information, eg. for giving the cache configuration for
cache simulation.</p>
<p>Counts can be "." to represent "N/A", eg. the number of
write misses for an instruction that doesn't write to
memory.</p>
<p>The number of counts in each
<code class="computeroutput">line</code> and the
<code class="computeroutput">summary_line</code> should not exceed
the number of events in the
<code class="computeroutput">event_line</code>.  If the number in
each <code class="computeroutput">line</code> is less, cg_annotate
treats those missing as though they were a "." entry.</p>
<p>A <code class="computeroutput">file_line</code> changes the
current file name.  A <code class="computeroutput">fn_line</code>
changes the current function name.  A
<code class="computeroutput">count_line</code> contains counts that
pertain to the current filename/fn_name.  A "fn="
<code class="computeroutput">file_line</code> and a
<code class="computeroutput">fn_line</code> must appear before any
<code class="computeroutput">count_line</code>s to give the context
of the first <code class="computeroutput">count_line</code>s.</p>
<p>Each <code class="computeroutput">file_line</code> should be
immediately followed by a
<code class="computeroutput">fn_line</code>.  "fi="
<code class="computeroutput">file_lines</code> are used to switch
filenames for inlined functions; "fe="
<code class="computeroutput">file_lines</code> are similar, but are
put at the end of a basic block in which the file name hasn't
been switched back to the original file name.  (fi and fe lines
behave the same, they are only distinguished to help
debugging.)</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="cg-tech-docs.summary"></a>2.8.燬ummary of performance features</h2></div></div></div>
<p>Quite a lot of work has gone into making the profiling as
fast as possible.  This is a summary of the important
features:</p>
<div class="itemizedlist"><ul type="disc">
<li><p>The basic block-level cost centre storage allows almost
    free cost centre lookup.</p></li>
<li><p>Only one function call is made per instruction
    simulated; even this accounts for a sizeable percentage of
    execution time, but it seems unavoidable if we want
    flexibility in the cache simulator.</p></li>
<li><p>Unchanging information about an instruction is stored
    in its cost centre, avoiding unnecessary argument pushing,
    and minimising UCode instrumentation bloat.</p></li>
<li><p>Summary counts are calculated at the end, rather than
    during execution.</p></li>
<li><p>The <code class="computeroutput">cachegrind.out</code>
    output files can contain huge amounts of information; file
    format was carefully chosen to minimise file sizes.</p></li>
</ul></div>
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="cg-tech-docs.annotate"></a>2.9.燗nnotation</h2></div></div></div>
<p>Annotation is done by cg_annotate.  It is a fairly
straightforward Perl script that slurps up all the cost centres,
and then runs through all the chosen source files, printing out
cost centres with them.  It too has been carefully optimised.</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="cg-tech-docs.extensions"></a>2.10.燬imilar work, extensions</h2></div></div></div>
<p>It would be relatively straightforward to do other
simulations and obtain line-by-line information about interesting
events.  A good example would be branch prediction -- all
branches could be instrumented to interact with a branch
prediction simulator, using very similar techniques to those
described above.</p>
<p>In particular, cg_annotate would not need to change -- the
file format is such that it is not specific to the cache
simulation, but could be used for any kind of line-by-line
information.  The only part of cg_annotate that is specific to
the cache simulation is the name of the input file
(<code class="computeroutput">cachegrind.out</code>), although it
would be very simple to add an option to control this.</p>
</div>
</div>
<div>
<br><table class="nav" width="100%" cellspacing="3" cellpadding="2" border="0" summary="Navigation footer">
<tr>
<td rowspan="2" width="40%" align="left">
<a accesskey="p" href="mc-tech-docs.html">&lt;&lt;