]> git.ipfire.org Git - thirdparty/valgrind.git/commitdiff
Updated Cachegrind docs: you have to use "valgrind --skin=cachegrind" to run
authorNicholas Nethercote <njn@valgrind.org>
Wed, 2 Oct 2002 11:47:12 +0000 (11:47 +0000)
committerNicholas Nethercote <njn@valgrind.org>
Wed, 2 Oct 2002 11:47:12 +0000 (11:47 +0000)
it as the "cachegrind" script is now dead.

git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1165

cachegrind/docs/manual.html

index 5c57e71f86944808a49ed9282ab11b67f188211d..85462560e69466be9e944f2e99ea7aeafd6f8839 100644 (file)
@@ -80,8 +80,8 @@ should profile your program as it will be normally run.
 
 The two steps are:
 <ol>
-  <li>Run your program with <code>cachegrind</code> in front of the
-      normal command line invocation.  When the program finishes,
+  <li>Run your program with <code>valgrind --skin=cachegrind</code> in front of
+      the normal command line invocation.  When the program finishes,
       Valgrind will print summary cache statistics. It also collects
       line-by-line information in a file
       <code>cachegrind.out.<i>pid</i></code>, where <code><i>pid</i></code>
@@ -175,17 +175,11 @@ interested to hear from anyone who does.
 <a name="profile"></a>
 <h3>1.3&nbsp; Profiling programs</h3>
 
-Cache profiling is enabled by using the <code>--cachesim=yes</code>
-option to the <code>valgrind</code> shell script.  Alternatively, it
-is probably more convenient to use the <code>cachegrind</code> script.
-Either way automatically turns off Valgrind's memory checking functions,
-since the cache simulation is slow enough already, and you probably
-don't want to do both at once.
-<p>
-To gather cache profiling information about the program <code>ls
--l</code>, type:
+Cache profiling is enabled by using the <code>--skin=cachegrind</code>
+option to the <code>valgrind</code> shell script.  To gather cache profiling
+information about the program <code>ls -l</code>, type:
 
-<blockquote><code>cachegrind ls -l</code></blockquote>
+<blockquote><code>valgrind --skin=cachegrind ls -l</code></blockquote>
 
 The program will execute (slowly).  Upon completion, summary statistics
 that look like this will be printed:
@@ -230,8 +224,8 @@ described in the next section.
 <p>
 Things to note about the <code>cachegrind.out.<i>pid</i></code> file:
 <ul>
-  <li>It is written every time <code>valgrind --cachesim=yes</code> or
-      <code>cachegrind</code> is run, and will overwrite any existing
+  <li>It is written every time <code>valgrind --skin=cachegrind</code>
+      is run, and will overwrite any existing
       <code>cachegrind.out.<i>pid</i></code> in the current directory (but
       that won't happen very often because it takes some time for process ids
       to be recycled).</li>
@@ -266,7 +260,9 @@ The interesting cache-simulation specific options are:
       <code>size</code> and <code>line_size</code> are measured in bytes.  The
       three items must be comma-separated, but with no spaces, eg:
 
-      <blockquote><code>cachegrind --I1=65535,2,64</code></blockquote>
+      <blockquote>
+      <code>valgrind --skin=cachegrind --I1=65535,2,64</code>
+      </blockquote>
 
       You can specify one, two or three of the I1/D1/L2 caches.  Any level not
       manually specified will be simulated using the configuration found in the
@@ -386,7 +382,7 @@ First up is a summary of the annotation options:
 </ul>
 
 Then follows summary statistics for the whole program. These are similar
-to the summary provided when running <code>cachegrind</code>.<p>
+to the summary provided when running <code>valgrind --skin=cachegrind</code>.<p>
   
 Then follows function-by-function statistics. Each function is
 identified by a <code>file_name:function_name</code> pair. If a column