From 3cc0c8f8fae2e345d5862a3747e1b7918c3f913f Mon Sep 17 00:00:00 2001 From: Nicholas Nethercote Date: Tue, 8 Apr 2003 11:08:45 +0000 Subject: [PATCH] Minor HTML fixes in docs, thanks to Arnaud Desitter. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1522 --- cachegrind/docs/cg_main.html | 46 +++++++++++++++-------------- coregrind/docs/coregrind_skins.html | 25 ++++++++-------- memcheck/docs/mc_techdocs.html | 14 ++++----- 3 files changed, 44 insertions(+), 41 deletions(-) diff --git a/cachegrind/docs/cg_main.html b/cachegrind/docs/cg_main.html index 9a9617f73..0a9d2955c 100644 --- a/cachegrind/docs/cg_main.html +++ b/cachegrind/docs/cg_main.html @@ -54,8 +54,7 @@ The two steps are: This step should be done every time you want to collect information about a new program, a changed program, or about the same program with different input. - -

+

  • Generate a function-by-function summary, and possibly annotate source files, using the supplied cg_annotate program. Source files to annotate can be @@ -66,14 +65,14 @@ The two steps are:

    This step can be performed as many times as you like for each Step 2. You may want to do multiple annotations showing - different information each time.

    -

    • + different information each time. +

    -The steps are described in detail in the following sections.

    +The steps are described in detail in the following sections. -

    4.3  Cache simulation specifics

    +

    4.3  Cache simulation specifics

    Cachegrind uses a simulation for a machine with a split L1 cache and a unified L2 cache. This configuration is used for all (modern) x86-based machines we @@ -85,20 +84,22 @@ The more specific characteristics of the simulation are as follows. + +

  • Inclusive L2 cache: the L2 cache replicates all the entries of the L1 cache. This is standard on Pentium chips, but AMD Athlons use an exclusive L2 cache that only holds blocks evicted - from L1. Ditto AMD Durons and most modern VIAs.

    • + from L1. Ditto AMD Durons and most modern VIAs. The cache configuration simulated (cache size, associativity and line size) is @@ -108,8 +109,9 @@ an early incarnation that doesn't give any cache information, then Cachegrind will fall back to using a default configuration (that of a model 3/4 Athlon). Cachegrind will tell you if this happens. You can manually specify one, two or all three levels (I1/D1/L2) of the cache from the command line using the ---I1, --D1 and --L2 options.

    +--I1, --D1 and --L2 options. +

    Other noteworthy behaviour:

    + +

  • Instructions that modify a memory location (eg. inc and dec) are counted as doing just a read, ie. a single data reference. This may seem strange, but since the write can never cause a miss (the read guarantees the block is in the cache) it's not very - interesting.

    - + interesting. +

    Thus it measures not the number of times the data cache is accessed, but the number of times a data cache miss could occur.

    • @@ -170,14 +173,14 @@ that look like this will be printed: Cache accesses for instruction fetches are summarised first, giving the number of fetches made (this is the number of instructions executed, which can be useful to know in its own right), the number of I1 misses, and the -number of L2 instruction (L2i) misses.

    - +number of L2 instruction (L2i) misses. +

    Cache accesses for data follow. The information is similar to that of the instruction fetches, except that the values are also shown split between reads and writes (note each row's rd and wr values add up -to the row's total).

    - -Combined instruction and data figures for the L2 cache follow that.

    +to the row's total). +

    +Combined instruction and data figures for the L2 cache follow that.

    4.5  Output file

    @@ -194,8 +197,7 @@ Things to note about the cachegrind.out.pid file: is run, and will overwrite any existing cachegrind.out.pid in the current directory (but that won't happen very often because it takes some time for process ids - to be recycled). -

    + to be recycled).

  • It can be huge: ls -l generates a file of about 350KB. Browsing a few files and web pages with a Konqueror built with full debugging information generates a file diff --git a/coregrind/docs/coregrind_skins.html b/coregrind/docs/coregrind_skins.html index 291dd3a06..a2b807e27 100644 --- a/coregrind/docs/coregrind_skins.html +++ b/coregrind/docs/coregrind_skins.html @@ -175,7 +175,7 @@ three spaces in which program code executes:

    2  Writing a Skin

    - +

    2.1  Why write a skin?

    Before you write a skin, you should have some idea of what it should do. What @@ -209,7 +209,7 @@ the number of times a particular function is called) to very intrusive (e.g. memcheck's memory checking). - +

    2.2  Suggested skins

    Here is a list of ideas we have had for skins that should not be too hard to @@ -279,7 +279,7 @@ implement. We would love to hear from anyone who implements these or other skins. - +

    2.3  How skins work

    Skins must define various functions for instrumenting programs that are called @@ -299,7 +299,7 @@ This magic is all done for you; the shared object used is chosen with the --skin option to the valgrind startup script. The default skin used is memcheck, Valgrind's original memory checker. - +

    2.4  Getting the code

    To write your own skin, you'll need to check out a copy of Valgrind from the @@ -325,7 +325,7 @@ cvs -z3 -d:pserver:anonymous@cvs.valgrind.sourceforge.net:/cvsroot/valgrind co - where TAG has the form VALGRIND_X_Y_Z for version X.Y.Z. - +

    2.5  Getting started

    Valgrind uses GNU automake and autoconf for the @@ -532,7 +532,7 @@ These just prepend longer strings in front of names to avoid potential namespace clashes. We strongly recommend using the SK_ macro for any global functions and variables in your skin.

    - +

    2.11  Words of Advice

    Writing and debugging skins is not trivial. Here are some suggestions for @@ -556,6 +556,7 @@ Valgrind with some effort: for (p = 0; p < 50000; p++) for (q = 0; q < 50000; q++) ; } +

    • and rebuild Valgrind. @@ -594,7 +595,7 @@ The other debugging command line options can be useful too (run valgrind Once a skin becomes more complicated, there are some extra things you may want/need to do. - +

    3.1  Suppressions

    If your skin reports errors and you want to suppress some common ones, you can @@ -603,7 +604,7 @@ add suppressions to the suppression files. The relevant files are these files by combining the relevant .supp files depending on the versions of linux, X and glibc on a system. - +

    3.2  Documentation

    If you are feeling conscientious and want to write some HTML documentation for @@ -636,7 +637,7 @@ name again):

    - +

    3.3  Regression tests

    Valgrind has some support for regression tests. If you want to write @@ -673,7 +674,7 @@ regression tests for your skin:

    - +

    3.4  Profiling

    To do simple tick-based profiling of a skin, include the line @@ -691,7 +692,7 @@ core profiling event numbers. See include/vg_skin.h for details and the ``memcheck'' skin for an example. - +

    3.5  Other makefile hackery

    If you add any directories under valgrind/foobar/, you will @@ -704,7 +705,7 @@ add them to the bin_SCRIPTS variable in valgrind/foobar/Makefile.am.

    - +

    3.5  Core/skin interface versions

    In order to allow for the core/skin interface to evolve over time, Valgrind diff --git a/memcheck/docs/mc_techdocs.html b/memcheck/docs/mc_techdocs.html index cd426f5ef..7b60bfc36 100644 --- a/memcheck/docs/mc_techdocs.html +++ b/memcheck/docs/mc_techdocs.html @@ -32,7 +32,7 @@ Detailed technical notes for hackers, maintainers and the overly-curious
    These notes pertain to snapshot 20020306

    -jseward@acm.org
    +    jseward@acm.org
    http://developer.kde.org/~sewardj
    Copyright © 2000-2002 Julian Seward

    @@ -363,7 +363,7 @@ performance or functionality. As a result:

  • The main dispatch loop, in VG_(dispatch), checks that translations do not set %ebp to any value different from VG_EBP_DISPATCH_CHECKED or - & VG_(baseBlock). In effect this test is free, + & VG_(baseBlock). In effect this test is free, and is permanently engaged.

  • There are a couple of ifdefed-out consistency checks I @@ -762,7 +762,7 @@ junk faster than you can possibly imagine.

    UCode operand tags: type Tag

    UCode is, more or less, a simple two-address RISC-like code. In -keeping with the x86 AT&T assembly syntax, generally speaking the +keeping with the x86 AT&T assembly syntax, generally speaking the first operand is the source operand, and the second is the destination operand, which is modified when the uinstr is notionally executed. @@ -1725,7 +1725,7 @@ Every 1000 basic blocks, we see if more signals have arrived. If so, VG_(deliver_signals) builds signal delivery frames on the client's stack, and allows their handlers to be run. Valgrind places in these signal delivery frames a bogus return address, -    VG_(signalreturn_bogusRA), and checks all jumps to see +VG_(signalreturn_bogusRA), and checks all jumps to see if any jump to it. If so, this is a sign that a signal handler is returning, and if so Valgrind removes the relevant signal frame from the client's stack, restores the from the signal frame the simulated @@ -2051,9 +2051,9 @@ void fooble ( void ) int spacer1; int b[10]; int spacer2; - VALGRIND_MAKE_NOACCESS(&spacer0, sizeof(int)); - VALGRIND_MAKE_NOACCESS(&spacer1, sizeof(int)); - VALGRIND_MAKE_NOACCESS(&spacer2, sizeof(int)); + VALGRIND_MAKE_NOACCESS(&spacer0, sizeof(int)); + VALGRIND_MAKE_NOACCESS(&spacer1, sizeof(int)); + VALGRIND_MAKE_NOACCESS(&spacer2, sizeof(int)); a[10] = 99; }