cl-manual.html

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

      "yes". Not recommand.</p></dd>
</dl>
</div>
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
<a name="cl-manual.options.activity"></a>5.4.3.燗ctivity options</h3></div></div></div>
<p>
These options specify when actions relating to event counts are to
be executed. For interactive control use
<code class="computeroutput">callgrind_control</code>.
</p>
<div class="variablelist">
<a name="cmd-options.activity"></a><dl>
<dt>
<a name="opt.dump-every-bb"></a><span class="term">
      <code class="option">--dump-every-bb=&lt;count&gt; [default: 0, never] </code>
    </span>
</dt>
<dd><p>Dump profile data every &lt;count&gt; basic blocks.
      Whether a dump is needed is only checked when Valgrinds internal
      scheduler is run. Therefore, the minimum setting useful is about 100000.
      The count is a 64-bit value to make long dump periods possible.
      </p></dd>
<dt>
<a name="opt.dump-before"></a><span class="term">
      <code class="option">--dump-before=&lt;prefix&gt; </code>
    </span>
</dt>
<dd><p>Dump when entering a function starting with &lt;prefix&gt;</p></dd>
<dt>
<a name="opt.zero-before"></a><span class="term">
      <code class="option">--zero-before=&lt;prefix&gt; </code>
    </span>
</dt>
<dd><p>Zero all costs when entering a function starting with &lt;prefix&gt;</p></dd>
<dt>
<a name="opt.dump-after"></a><span class="term">
      <code class="option">--dump-after=&lt;prefix&gt; </code>
    </span>
</dt>
<dd><p>Dump when leaving a function starting with &lt;prefix&gt;</p></dd>
</dl>
</div>
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
<a name="cl-manual.options.collection"></a>5.4.4.燚ata collection options</h3></div></div></div>
<p>
These options specify when events are to be aggregated into event counts.
Also see <a href="cl-manual.html#cl-manual.limits">Limiting range of event collection</a>.</p>
<div class="variablelist">
<a name="cmd-options.collection"></a><dl>
<dt>
<a name="opt.instr-atstart"></a><span class="term">
      <code class="option">--instr-atstart=&lt;yes|no&gt; [default: yes] </code>
    </span>
</dt>
<dd>
<p>Specify if you want Callgrind to start simulation and
      profiling from the beginning of the program.  
      When set to <code class="computeroutput">no</code>, 
      Callgrind will not be able
      to collect any information, including calls, but it will have at
      most a slowdown of around 4, which is the minimum Valgrind
      overhead.  Instrumentation can be interactively switched on via
      <code class="computeroutput">callgrind_control -i on</code>.</p>
<p>Note that the resulting call graph will most probably not
      contain <code class="computeroutput">main</code>, but will contain all the
      functions executed after instrumentation was switched on.
      Instrumentation can also programatically switched on/off. See the
      Callgrind include file
      <code class="computeroutput">&lt;callgrind.h&gt;</code> for the macro
      you have to use in your source code.</p>
<p>For cache
      simulation, results will be less accurate when switching on
      instrumentation later in the program run, as the simulator starts
      with an empty cache at that moment.  Switch on event collection
      later to cope with this error.</p>
</dd>
<dt>
<a name="opt.collect-atstart"></a><span class="term">
      <code class="option">--collect-atstart=&lt;yes|no&gt; [default: yes] </code>
    </span>
</dt>
<dd>
<p>Specify whether event collection is switched on at beginning
      of the profile run.</p>
<p>To only look at parts of your program, you have two
      possibilities:</p>
<div class="orderedlist"><ol type="1">
<li><p>Zero event counters before entering the program part you
        want to profile, and dump the event counters to a file after
        leaving that program part.</p></li>
<li><p>Switch on/off collection state as needed to only see
          event counters happening while inside of the program part you
          want to profile.</p></li>
</ol></div>
<p>The second option can be used if the program part you want to
      profile is called many times. Option 1, i.e. creating a lot of
      dumps is not practical here.</p>
<p>Collection state can be
      toggled at entry and exit of a given function with the
      option <a href="cl-manual.html#opt.toggle-collect">--toggle-collect</a>.  If you use this flag, 
      collection
      state should be switched off at the beginning.  Note that the
      specification of <code class="computeroutput">--toggle-collect</code>
      implicitly sets
      <code class="computeroutput">--collect-state=no</code>.</p>
<p>Collection state can be toggled also by using a Valgrind
      Client Request in your application.  For this, include
      <code class="computeroutput">valgrind/callgrind.h</code> and specify
      the macro
      <code class="computeroutput">CALLGRIND_TOGGLE_COLLECT</code> at the
      needed positions. This only will have any effect if run under
      supervision of the Callgrind tool.</p>
</dd>
<dt>
<a name="opt.toggle-collect"></a><span class="term">
      <code class="option">--toggle-collect=&lt;prefix&gt; </code>
    </span>
</dt>
<dd><p>Toggle collection on entry/exit of a function whose name
      starts with
      &lt;prefix&gt;.</p></dd>
<dt>
<a name="opt.collect-jumps"></a><span class="term">
      <code class="option">--collect-jumps=&lt;no|yes&gt; [default: no] </code>
    </span>
</dt>
<dd><p>This specifies whether information for (conditional) jumps
      should be collected.  As above, callgrind_annotate currently is not
      able to show you the data.  You have to use KCachegrind to get jump
      arrows in the annotated code.</p></dd>
</dl>
</div>
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
<a name="cl-manual.options.separation"></a>5.4.5.燙ost entity separation options</h3></div></div></div>
<p>
These options specify how event counts should be attributed to execution
contexts.
More specifically, they specify e.g. if the recursion level or the
call chain leading to a function should be accounted for, and whether the
thread ID should be remembered.
Also see <a href="cl-manual.html#cl-manual.cycles">Avoiding cycles</a>.</p>
<div class="variablelist">
<a name="cmd-options.separation"></a><dl>
<dt>
<a name="opt.separate-threads"></a><span class="term">
      <code class="option">--separate-threads=&lt;no|yes&gt; [default: no] </code>
    </span>
</dt>
<dd><p>This option specifies whether profile data should be generated
      separately for every thread. If yes, the file names get "-threadID"
      appended.</p></dd>
<dt>
<a name="opt.fn-recursion"></a><span class="term">
      <code class="option">--fn-recursion=&lt;level&gt; [default: 2] </code>
    </span>
</dt>
<dd><p>Separate function recursions, maximal &lt;level&gt;.
      See <a href="cl-manual.html#cl-manual.cycles">Avoiding cycles</a>.</p></dd>
<dt>
<a name="opt.fn-caller"></a><span class="term">
      <code class="option">--fn-caller=&lt;callers&gt; [default: 0] </code>
    </span>
</dt>
<dd><p>Separate contexts by maximal &lt;callers&gt; functions in the
      call chain. See <a href="cl-manual.html#cl-manual.cycles">Avoiding cycles</a>.</p></dd>
<dt>
<a name="opt.skip-plt"></a><span class="term">
      <code class="option">--skip-plt=&lt;no|yes&gt; [default: yes] </code>
    </span>
</dt>
<dd><p>Ignore calls to/from PLT sections.</p></dd>
<dt>
<a name="opt.fn-skip"></a><span class="term">
      <code class="option">--fn-skip=&lt;function&gt; </code>
    </span>
</dt>
<dd>
<p>Ignore calls to/from a given function.  E.g. if you have a
      call chain A &gt; B &gt; C, and you specify function B to be
      ignored, you will only see A &gt; C.</p>
<p>This is very convenient to skip functions handling callback
      behaviour. E.g. for the SIGNAL/SLOT mechanism in QT, you only want
      to see the function emitting a signal to call the slots connected
      to that signal. First, determine the real call chain to see the
      functions needed to be skipped, then use this option.</p>
</dd>
<dt>
<a name="opt.fn-group"></a><span class="term">
      <code class="option">--fn-group&lt;number&gt;=&lt;function&gt; </code>
    </span>
</dt>
<dd><p>Put a function into a separate group. This influences the
      context name for cycle avoidance. All functions inside of such a
      group are treated as being the same for context name building, which
      resembles the call chain leading to a context. By specifying function
      groups with this option, you can shorten the context name, as functions
      in the same group will not appear in sequence in the name. </p></dd>
<dt>
<a name="opt.fn-recursion-num"></a><span class="term">
      <code class="option">--fn-recursion&lt;number&gt;=&lt;function&gt; </code>
    </span>
</dt>
<dd><p>Separate &lt;number&gt; recursions for &lt;function&gt;.
      See <a href="cl-manual.html#cl-manual.cycles">Avoiding cycles</a>.</p></dd>
<dt>
<a name="opt.fn-caller-num"></a><span class="term">
      <code class="option">--fn-caller&lt;number&gt;=&lt;function&gt; </code>
    </span>
</dt>
<dd><p>Separate &lt;number&gt; callers for &lt;function&gt;.
      See <a href="cl-manual.html#cl-manual.cycles">Avoiding cycles</a>.</p></dd>
</dl>
</div>
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
<a name="cl-manual.options.simulation"></a>5.4.6.燙ache simulation options</h3></div></div></div>
<div class="variablelist">
<a name="cmd-options.simulation"></a><dl>
<dt>
<a name="opt.simulate-cache"></a><span class="term">
      <code class="option">--simulate-cache=&lt;yes|no&gt; [default: no] </code>
    </span>
</dt>
<dd><p>Specify if you want to do full cache simulation.  By default,
      only instruction read accesses will be profiled.</p></dd>
</dl>
</div>
</div>
</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="cg-manual.html">&lt;&lt;