|
From: <sv...@va...> - 2005-07-25 23:18:48
|
Author: njn
Date: 2005-07-26 00:18:44 +0100 (Tue, 26 Jul 2005)
New Revision: 4259
Log:
Clean up command-line args info in the manual and man page for 3.0.0
release. =20
Modified:
trunk/docs/valgrind.1
trunk/docs/xml/manual-core.xml
trunk/memcheck/docs/mc-manual.xml
Modified: trunk/docs/valgrind.1
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/docs/valgrind.1 2005-07-25 23:18:04 UTC (rev 4258)
+++ trunk/docs/valgrind.1 2005-07-25 23:18:44 UTC (rev 4259)
@@ -1,7 +1,7 @@
.TH VALGRIND "1" "" ""
=20
.SH NAME
-\fBvalgrind \fP- a memory debugger for x86-linux
+\fBvalgrind \fP- a suite of tools for debugging and profiling programs
=20
.SH SYNOPSIS
.nf
@@ -11,8 +11,8 @@
.fi
=20
.SH DESCRIPTION
-\fBvalgrind\fP is a flexible program for debugging and profiling Linux-x=
86
-executables. It consists of a core, which provides a synthetic x86 CPU
+\fBvalgrind\fP is a flexible program for debugging and profiling Linux
+executables. It consists of a core, which provides a synthetic CPU
in software, and a series of "tools", each of which is a debugging or
profiling tool. The architecture is modular, so that new tools can be
created easily and without disturbing the existing structure.
@@ -125,17 +125,25 @@
default debugger is gdb. This option is a template that is expanded by
\fBvalgrind\fP at runtime. \fB%f\fP is replaced with the executable's
file name and \fB%p\fP is replaced by the process ID of the executable.
+
.TP
.B
+--demangle=3D<yes|no> [default: yes]
+Enable or disable automatic demangling (decoding) of C++ names. Enabled =
by
+default. When enabled, \fBvalgrind\fP will attempt to translate encoded
+C++ procedure names back to something approaching the original. The
+demangler handles symbols mangled by g++ versions 2.X and 3.X.
=20
+.TP
+.B
--error-limit=3D<yes|no> [default: yes]
When enabled, \fBvalgrind\fP stops reporting errors after 30000 in total=
,
or 300 different ones, have been seen. This is to stop the error trackin=
g
machinery from becoming a huge performance overhead in programs with
many errors.
+
.TP
.B
-
--gen-suppressions=3D<yes|no> [default: no]
When enabled, \fBvalgrind\fP will pause after every error shown and
print the line:
@@ -174,6 +182,12 @@
=20
.TP
.B
+--input-fd=3D<number> [default: 0, stdin]
+Specify the file descriptor to use for reading input from the user. This
+is used whenever \fBvalgrind\fP needs to prompt the user for a decision.
+
+.TP
+.B
--log-file=3D<filename>
Specifies that \fBvalgrind\fP should send all of its messages to the
specified file. In fact, the file name used is created by concatenating
@@ -182,6 +196,39 @@
=20
.TP
.B
+--log-file-exactly=3D<filename>
+Just like \fB--log-file\fB, but the ".pid" suffix is not added. If you
+trace multiple processes with Valgrind when using this option the log
+file may get all messed up.
+
+.TP
+.B
+--log-fd=3D<number> [default: 2, stderr]
+Specifies that \fBvalgrind\fP should send all of its messages to
+the specified file descriptor. The default, 2, is the standard error
+channel (stderr). Note that this may interfere with the client's own
+use of stderr.
+
+.TP
+.B
+--log-file-qualifier=3D<VAR>
+Specifies that \fBvalgrind\fB should send all of its messages to the
+file named by the environment variable \fB$VAR\fB. This is useful when
+running MPI programs.
+
+.TP
+.B
+--log-socket=3D<ip-address:port-number>
+Specifies that \fBvalgrind\fP should send all of its messages to the
+specified port at the specified IP address. The port may be omitted,
+in which case port 1500 is used. If a connection cannot be made to
+the specified socket, \fBvalgrind\fP falls back to writing output to
+the standard error (stderr). This option is intended to be used in
+conjunction with the \fBvalgrind-listener\fP program. For further detail=
s,
+see section 2.3 of the user manual.
+
+.TP
+.B
--num-callers=3D<number> [default=3D12]
By default, \fBvalgrind\fP shows 12 levels of function call names to
help you identify program locations. You can change that number with
@@ -206,12 +253,25 @@
=20
.TP
.B
+--show-below-main=3D<yes|no> [default: no]
+When enabled, this option causes full stack backtraces to be emited,
+including the part before \fBmain\fP in your program (subject to the
+\fB--num-callers\fP option.) When disabled, only the part of the stack
+backtrace up to and including main is printed.
+
+.TP
+.B
--suppressions=3D<filename> [default: $PREFIX/lib/\fBvalgrind\fP/default=
.supp]
Specifies an extra file from which to read descriptions of errors to
suppress. You may specify up to 10 additional suppression files.
=20
.TP
.B
+--time-stamp=3D<yes|no> [default: no]
+When enabled, a time-stamp is added to all log messages.
+
+.TP
+.B
--tool=3D<toolname> [default: memcheck]
Specify which tool to use. The default tool is memcheck.
=20
@@ -328,14 +388,6 @@
errors to be reported by \fBmemcheck\fP, so it's usually a good idea to
leave this enabled.
=20
-.TP
-.B
---cleanup=3D<yes|no> [default: yes]
-\fBThis is a flag to help debug valgrind itself. It is of no use to
-end-users\fP. When enabled, various improvments are applied to the
-post-instrumented intermediate code, aimed at removing redundant value
-checks.
-
.SH CACHEGRIND OPTIONS
=20
.TP
@@ -425,7 +477,7 @@
.B
--alignment=3D<number> [default: 8]
By default \fBvalgrind\fP's malloc, realloc, etc, return 8-byte aligned
-addresses. These are suitable for any accesses on x86 processors. Some
+addresses. These are suitable for any accesses on most processors. Some
programs might however assume that malloc et al return 16- or more
aligned memory. These programs are broken and should be fixed, but if
this is impossible for whatever reason the alignment can be increased
@@ -434,100 +486,6 @@
=20
.TP
.B
---branchpred=3D<yes|no> [default: no]
-This option enables the generation of static branch prediction hints.
-In theory this allows the real CPU to do a better job of running the
-generated code, but in practice it makes almost no measurable difference=
.
-It may have a large effect on some x86 implementations.
-
-.TP
-.B
---chain-bb=3D<yes|no> [default: yes]
-Enables basic-block chaining. If basic-block chaining is disabled,
-the synthetic CPU returns to the scheduler after interpreting each basic
-block. With basic block chaining enabled, it can immediately proceed to
-the next basic block. This almost always results in a performance gain,
-so it is enabled by default.
-
-.TP
-.B
---command-line-only=3D<yes|no> [default: no]
-Normally, \fBvalgrind\fP will look for command-line options in the
-following locations:
-.RS
-.TP
-- The \fBvalgrind\fP command line
-.TP
-- The \fB\.valgrindrc\fP file in the invocation directory
-.TP
-- The \fB\.valgrindrc\fP file in users home directory
-.TP
-- The \fB$VALGRIND_OPTS\fP environment variable
-.P
-
-When this option is enabled, \fBvalgrind\fP will only look at the comman=
d
-line for options.
-.RE
-
-.TP
-.B
---demangle=3D<yes|no> [default: yes]
-Enable or disable automatic demangling (decoding) of C++ names. Enabled =
by
-default. When enabled, \fBvalgrind\fP will attempt to translate encoded
-C++ procedure names back to something approaching the original. The
-demangler handles symbols mangled by g++ versions 2.X and 3.X.
-
-.TP
-.B
---dump-error=3D<number>
-After the program has exited, show gory details of the translation of
-the basic block containing the \fB<number>\fP'th error context. When
-used with --single-step=3Dyes, can show the exact x86 instruction causin=
g
-an error. This is all fairly dodgy and doesn't work at all if threads
-are involved.
-
-.TP
-.B
---exec=3D<filename>
-Specify the executable to run. If this is specified, it takes precedence
-over the \fByour-program\fP executable from the command-line. If this i=
s
-not specified, \fBvalgrind\fP searches the path for the \fByour-program\=
fP
-executable, just like a regular shell would.
-
-.TP
-.B
---input-fd=3D<number> [default: 0, stdin]
-Specify the file descriptor to use for reading input from the user. This
-is used whenever \fBvalgrind\fP needs to prompt the user for a decision.
-
-.TP
-.B
---log-fd=3D<number> [default: 2, stderr]
-Specifies that \fBvalgrind\fP should send all of its messages to
-the specified file descriptor. The default, 2, is the standard error
-channel (stderr). Note that this may interfere with the client's own
-use of stderr.
-
-.TP
-.B
---log-socket=3D<ip-address:port-number>
-Specifies that \fBvalgrind\fP should send all of its messages to the
-specified port at the specified IP address. The port may be omitted,
-in which case port 1500 is used. If a connection cannot be made to
-the specified socket, \fBvalgrind\fP falls back to writing output to
-the standard error (stderr). This option is intended to be used in
-conjunction with the \fBvalgrind-listener\fP program. For further detail=
s,
-see section 2.3 of the user manual.
-
-.TP
-.B
---optimise=3D<yes|no> [default: yes]
-When enabled, various improvements are applied to the intermediate code,
-mainly aimed at allowing the simulated CPU's registers to be cached in
-the real CPU's registers over several simulated instructions.
-
-.TP
-.B
--pointercheck=3D<yes|no> [default: yes]
When enabled, enforces client address space limits. If this option is
disabled, the client program has full and unfettered access to the part
@@ -563,27 +521,6 @@
=20
.TP
.B
---show-below-main=3D<yes|no> [default: no]
-When enabled, this option causes full stack backtraces to be emited,
-including the part before \fBmain\fP in your program (subject to the
-\fB--num-callers\fP option.) When disabled, only the part of the stack
-backtrace up to and including main is printed.
-
-.TP
-.B
---single-step=3D<yes|no> [default: no]
-When enabled, each x86 insn is translated separately into instrumented
-code. When disabled, translation is done on a per-basic-block basis,
-giving much better translations. This is needed when running
-\fBvalgrind\fP under \fBvalgrind\fP.
-
-.TP
-.B
---time-stamp=3D<yes|no> [default: no]
-When enabled, a time-stamp is added to all log messages.
-
-.TP
-.B
--weird-hacks=3Dhack1,hack2,\.\.\.
Pass miscellaneous hints to \fBvalgrind\fP which slightly modify the
simulated behaviour in nonstandard or dangerous ways, possibly to help
@@ -609,72 +546,8 @@
=20
.TP
.B
---profile=3D<yes|no> [default: no]
-When enabled, does crude internal profiling of \fBvalgrind\fP itself. Th=
is
-is not for profiling your programs. Rather it is to allow the developers
-to assess where \fBvalgrind\fP is spending its time. The tools must be
-built for profiling for this to work.
+Valgrind has several debugging options that are mostly of use to develop=
ers. Use \fB--help-debug\fB to show them.
=20
-.TP
-.B
---sanity-level=3D<number> [default: 1]
-Set the level of sanity checking to perform. This is used for debugging
-\fBvalgrind\fP. Setting this to 2 or higher can cause more internal
-sanity checks to be performed, but can slow your program down
-appreciably. Setting this to 0 disables sanity checks.
-
-.TP
-.B
---trace-codegen=3D<bitmask>
-Produce lots of output showing exactly how \fBvalgrind\fP is translating
-each basic block. The argument to this option is a 5-bit wide bitmask.
-Each bit refers to a specific feature to trace. If the bit is 1, the
-feature is traced. If it is 0, the feature is not traced.
-
-.RS
-The traced features are:
-.TP
-Bit 1: basic-block disassembly
-.TP
-Bit 2: optimization phase
-.TP
-Bit 3: tool instrumentation
-.TP
-Bit 4: register allocation
-.TP
-Bit 5: final code generation
-.RE
-
-.TP
-.B
---trace-malloc=3D<yes|no> [default: no]
-Enable or disable tracing of malloc, free and other memory-manager calls=
.
-
-.TP
-.B
---trace-redir=3D<yes|no> [default: no]
-Enable or disable tracing of function redirection.
-
-.TP
-.B
---trace-sched=3D<yes|no> [default: no]
-Enable or disable tracing of thread scheduling events.
-
-.TP
-.B
---trace-signals=3D<yes|no> [default: no]
-Enable or disable tracing of signal handling.
-
-.TP
-.B
---trace-syscalls=3D<yes|no> [default: no]
-Enable or disable tracing of system call intercepts.
-
-.TP
-.B
---trace-symtab=3D<yes|no> [default: no]
-Enable or disable tracing of symbol table reading.
-
.SH SEE ALSO
/usr/share/doc/\fBvalgrind\fP/html/manual.html
=20
Modified: trunk/docs/xml/manual-core.xml
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/docs/xml/manual-core.xml 2005-07-25 23:18:04 UTC (rev 4258)
+++ trunk/docs/xml/manual-core.xml 2005-07-25 23:18:44 UTC (rev 4259)
@@ -610,6 +610,13 @@
</listitem>
=20
<listitem>
+ <para><computeroutput>-q --quiet</computeroutput></para>
+ <para>Run silently, and only print error messages. Useful if
+ you are running regression tests or have some other automated
+ test machinery.</para>
+ </listitem>
+
+ <listitem>
<para><computeroutput>-v --verbose</computeroutput></para>
<para>Be more verbose. Gives extra information on various
aspects of your program, such as: the shared objects loaded,
@@ -619,13 +626,6 @@
</listitem>
=20
<listitem>
- <para><computeroutput>-q --quiet</computeroutput></para>
- <para>Run silently, and only print error messages. Useful if
- you are running regression tests or have some other automated
- test machinery.</para>
- </listitem>
-
- <listitem>
<para><computeroutput>--trace-children=3Dno</computeroutput>
[default]</para>
<para><computeroutput>--trace-children=3Dyes</computeroutput></para>
@@ -635,6 +635,23 @@
</listitem>
=20
<listitem>
+ <para><computeroutput>--track-fds=3Dno</computeroutput> [default]</p=
ara>
+ <para><computeroutput>--track-fds=3Dyes</computeroutput></para>
+ <para>When enabled, Valgrind will print out a list of open
+ file descriptors on exit. Along with each file descriptor,
+ Valgrind prints out a stack backtrace of where the file was
+ opened and any details relating to the file descriptor such
+ as the file name or socket details.</para>
+ </listitem>
+
+ <listitem>
+ <para><computeroutput>--time-stamp=3Dno</computeroutput> [default]</=
para>
+ <para><computeroutput>--time-stamp=3Dyes</computeroutput></para>
+ <para>When enabled, Valgrind will precede each message with the
+ current time and date.</para>
+ </listitem>
+
+ <listitem>
<para><computeroutput>--log-fd=3D<number></computeroutput>
[default: 2, stderr]</para>
<para>Specifies that Valgrind should send all of its messages
@@ -696,6 +713,23 @@
<itemizedlist>
=20
<listitem>
+ <para><computeroutput>--xml=3Dno</computeroutput> [default]</para>
+ <para><computeroutput>--xml=3Dyes</computeroutput></para>
+ <para>When enabled, output will be in XML format. This is aimed at
+ making life easier for tools that consume Valgrind's output as input=
,
+ such as GUI front ends. Currently this option only works with Memch=
eck
+ and Nulgrind.
+ </para>
+ </listitem>
+ =20
+ <listitem>
+ <para><computeroutput>--xml-user-comment=3D<string></computero=
utput> [default=3D""]</para>
+ <para>Embeds an extra user comment string in the XML output. Only w=
orks
+ with <computeroutput>--xml=3Dyes</computeroutput> is specified; ign=
ored
+ otherwise.</para>
+ </listitem>
+ =20
+ <listitem>
<para><computeroutput>--demangle=3Dno</computeroutput></para>
<para><computeroutput>--demangle=3Dyes</computeroutput> [default]</p=
ara>
<para>Disable/enable automatic demangling (decoding) of C++
@@ -802,48 +836,6 @@
</listitem>
=20
<listitem>
- <para><computeroutput>--track-fds=3Dno</computeroutput> [default]</p=
ara>
- <para><computeroutput>--track-fds=3Dyes</computeroutput></para>
- <para>When enabled, Valgrind will print out a list of open
- file descriptors on exit. Along with each file descriptor,
- Valgrind prints out a stack backtrace of where the file was
- opened and any details relating to the file descriptor such
- as the file name or socket details.</para>
- </listitem>
-
- <listitem>
- <para><computeroutput>--max-stackframe=3D<number></computerout=
put>
- [default=3D2000000]
- </para>
- <para>You may need to use this option if your program has large
- stack-allocated arrays. Valgrind keeps track of your program's
- stack pointer. If it changes by more than the threshold amount,
- Valgrind assumes your program is switching to a different stack,
- and Memcheck behaves differently than it would for a stack pointer
- change smaller than the threshold. Usually this heuristic works
- well. However, if your program allocates large structures on the
- stack, this heuristic will be fooled, and Memcheck will
- subsequently report large numbers of invalid stack accesses. This
- option allows you to change the threshold to a different value.
- </para>
- <para>
- You should only consider use of this flag if Valgrind's debug output
- directs you to do so. In that case it will tell you the new
- threshold you should specify.
- </para>
- <para>
- In general, allocating large structures on the stack is a bad
- idea, because (1) you can easily run out of stack space,
- especially on systems with limited memory or which expect to
- support large numbers of threads each with a small stack, and (2)
- because the error checking performed by Memcheck is more effective
- for heap-allocated data than for stack-allocated data. If you
- have to use this flag, you may wish to consider rewriting your
- code to allocate on the heap rather than on the stack.
- </para>
- </listitem>
-
- <listitem>
<para><computeroutput>--db-attach=3Dno</computeroutput> [default]</p=
ara>
<para><computeroutput>--db-attach=3Dyes</computeroutput></para>
<para>When enabled, Valgrind will pause after every error
@@ -910,6 +902,38 @@
alternative file descriptor from which to read input.</para>
</listitem>
=20
+ <listitem>
+ <para><computeroutput>--max-stackframe=3D<number></computerout=
put>
+ [default=3D2000000]
+ </para>
+ <para>You may need to use this option if your program has large
+ stack-allocated arrays. Valgrind keeps track of your program's
+ stack pointer. If it changes by more than the threshold amount,
+ Valgrind assumes your program is switching to a different stack,
+ and Memcheck behaves differently than it would for a stack pointer
+ change smaller than the threshold. Usually this heuristic works
+ well. However, if your program allocates large structures on the
+ stack, this heuristic will be fooled, and Memcheck will
+ subsequently report large numbers of invalid stack accesses. This
+ option allows you to change the threshold to a different value.
+ </para>
+ <para>
+ You should only consider use of this flag if Valgrind's debug output
+ directs you to do so. In that case it will tell you the new
+ threshold you should specify.
+ </para>
+ <para>
+ In general, allocating large structures on the stack is a bad
+ idea, because (1) you can easily run out of stack space,
+ especially on systems with limited memory or which expect to
+ support large numbers of threads each with a small stack, and (2)
+ because the error checking performed by Memcheck is more effective
+ for heap-allocated data than for stack-allocated data. If you
+ have to use this flag, you may wish to consider rewriting your
+ code to allocate on the heap rather than on the stack.
+ </para>
+ </listitem>
+
</itemizedlist>
</sect2>
=20
@@ -940,8 +964,8 @@
</sect2>
=20
=20
- <sect2 id=3D"manual-core.rareopts" xreflabel=3D"Rare Options">
- <title>Rare Options</title>
+ <sect2 id=3D"manual-core.rareopts" xreflabel=3D"Uncommon Options">
+ <title>Uncommon Options</title>
=20
<para>These options apply to all tools, as they affect certain
obscure workings of the Valgrind core. Most people won't need
@@ -1027,6 +1051,27 @@
the same functionality.</para>
</listitem>
=20
+ <listitem>
+ <para><computeroutput>--show-emwarns=3Dno</computeroutput> [default]=
</para>
+ <para><computeroutput>--show-emwarns=3Dyes</computeroutput></para>
+ <para>When enabled, Valgrind will emit warnings about its CPU emulat=
ion
+ in certain cases. These are usually not interesting.</para>
+ </listitem>
+
+ <listitem>
+ <para><computeroutput>--smc-check=3Dnone</computeroutput></para>
+ <para><computeroutput>--smc-check=3Dstack</computeroutput> [default]=
</para>
+ <para><computeroutput>--smc-check=3Dall</computeroutput></para>
+ <para>This option controls Valgrind's detection of self-modifying co=
de.
+ Valgrind can do no detection, detect self-modifying code on the stac=
k,
+ or detect self-modifying code anywhere. Note that the default optio=
n
+ will catch the vast majority of cases, as far as we know. Running w=
ith
+ <computeroutput>all</computeroutput> will slow Valgrind down greatly
+ (but running with <computeroutput>none</computeroutput> will rarely
+ speed things up, since very little code gets put on the stack for mo=
st
+ programs). </para>
+ </listitem>
+
</itemizedlist>
</sect2>
=20
@@ -1035,123 +1080,10 @@
<title>Debugging Valgrind Options</title>
=20
<para>There are also some options for debugging Valgrind itself.
-You shouldn't need to use them in the normal run of things.
-Nevertheless:</para>
+You shouldn't need to use them in the normal run of things. If you
+wish to see the list, use the <computeroutput>--help-debug</computeroutp=
ut>
+option.</para>
=20
- <itemizedlist>
-
- <listitem>
- <para><computeroutput>--single-step=3Dno</computeroutput>
- [default]</para>
- <para><computeroutput>--single-step=3Dyes</computeroutput></para>
- <para>When enabled, each instruction is translated separately
- into instrumented code. When disabled, translation is done
- on a per-basic-block basis, giving much better
- translations. This option is very useful if your program expects
- precise exceptions (if it, for example, inspects or modifies registe=
r
- state from within a signal handler).
- </para>
- </listitem>
-
- <listitem>
- <para><computeroutput>--optimise=3Dno</computeroutput></para>
- <para><computeroutput>--optimise=3Dyes</computeroutput> [default]</p=
ara>
- <para>When enabled, various improvements are applied to the
- intermediate code, mainly aimed at allowing the simulated
- CPU's registers to be cached in the real CPU's registers over
- several simulated instructions.</para>
- </listitem>
-
- <listitem>
- <para><computeroutput>--profile=3Dno</computeroutput></para>
- <para><computeroutput>--profile=3Dyes</computeroutput> [default]</pa=
ra>
- <para>When enabled, does crude internal profiling of Valgrind
- itself. This is not for profiling your programs. Rather it
- is to allow the developers to assess where Valgrind is
- spending its time. The tools must be built for profiling for
- this to work.</para>
- </listitem>
-
- <listitem>
- <para><computeroutput>--trace-syscalls=3Dno</computeroutput>
- [default]</para>
- <para><computeroutput>--trace-syscalls=3Dyes</computeroutput></para>
- <para>Enable/disable tracing of system call intercepts.</para>
- </listitem>
-
- <listitem>
- <para><computeroutput>--trace-signals=3Dno</computeroutput>
- [default]</para>
- <para><computeroutput>--trace-signals=3Dyes</computeroutput></para>
- <para>Enable/disable tracing of signal handling.</para>
- </listitem>
-
- <listitem>
- <para><computeroutput>--trace-sched=3Dno</computeroutput>
- [default]</para>
- <para><computeroutput>--trace-sched=3Dyes</computeroutput></para>
- <para>Enable/disable tracing of thread scheduling events.</para>
- </listitem>
-
- <listitem>
- <para><computeroutput>--trace-pthread=3Dnone</computeroutput>
- [default]</para>
- <para><computeroutput>--trace-pthread=3Dsome</computeroutput></para>
- <para><computeroutput>--trace-pthread=3Dall</computeroutput></para>
- <para>Specifies amount of trace detail for pthread-related
- events.</para>
- </listitem>
-
- <listitem>
- <para><computeroutput>--trace-symtab=3Dno</computeroutput>
- [default]</para>
- <para><computeroutput>--trace-symtab=3Dyes</computeroutput></para>
- <para>Enable/disable tracing of symbol table reading and line
- number info reading.</para>
- </listitem>
-
- <listitem>
- <para><computeroutput>--trace-cfi=3Dno</computeroutput>
- [default]</para>
- <para><computeroutput>--trace-cfi=3Dyes</computeroutput></para>
- <para>Enable/disable tracing of call-frame-info reading.
- Call-frame-info (CFI) is information inserted by compilers=20
- which describes the relationship between adjacent call frames.
- On architectures which by default do not use a frame pointer,=20
- such as AMD64, this information is essential for creating stack=20
- snapshots.</para>
- </listitem>
-
- <listitem>
- <para><computeroutput>--trace-malloc=3Dno</computeroutput>
- [default]</para>
- <para><computeroutput>--trace-malloc=3Dyes</computeroutput></para>
- <para>Enable/disable tracing of malloc/free (et al)
- intercepts.</para>
- </listitem>
-
- <listitem>
- <para><computeroutput>--trace-codegen=3DXXXXX</computeroutput>
- [default: 00000]</para>
- <para>Enable/disable tracing of code generation. Code can be
- printed at five different stages of translation; each
- <computeroutput>X</computeroutput> element must be 0 or
- 1.</para>
- </listitem>
-
- <listitem>
- <para><computeroutput>--dump-error=3D<number></computeroutput>
- [default: inactive]</para>
- <para>After the program has exited, show gory details of the
- translation of the basic block containing the <number>'th
- error context. When used with
- <computeroutput>--single-step=3Dyes</computeroutput>, can show
- the exact instruction causing an error. This is all
- fairly dodgy and doesn't work at all if threads are
- involved.</para>
- </listitem>
-
- </itemizedlist>
</sect2>
=20
=20
Modified: trunk/memcheck/docs/mc-manual.xml
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/memcheck/docs/mc-manual.xml 2005-07-25 23:18:04 UTC (rev 4258)
+++ trunk/memcheck/docs/mc-manual.xml 2005-07-25 23:18:44 UTC (rev 4259)
@@ -62,15 +62,18 @@
<itemizedlist id=3D"leakcheck">
<listitem>
<para><computeroutput>--leak-check=3Dno</computeroutput>
+ <para><computeroutput>--leak-check=3Dsummary</computeroutput>
[default]</para>
- <para><computeroutput>--leak-check=3Dyes</computeroutput></para>
+ <para><computeroutput>--leak-check=3Dfull</computeroutput></para>
<para>When enabled, search for memory leaks when the client
program finishes. A memory leak means a malloc'd block,
which has not yet been free'd, but to which no pointer can be
found. Such a block can never be free'd by the program,
- since no pointer to it exists. Leak checking is disabled by
- default because it tends to generate dozens of error
- messages.</para>
+ since no pointer to it exists. If set to
+ <computeroutput>summary</computeroutput>, it says how many leaks occ=
urred.
+ If set to <computeroutput>all</computeroutput>, it gives details of =
each
+ individual leak.</para>
+
</listitem>
=20
<listitem id=3D"showreach">
@@ -182,15 +185,6 @@
enabled.</para>
</listitem>
=20
- <listitem id=3D"cleanup">
- <para><computeroutput>--cleanup=3Dno</computeroutput></para>
- <para><computeroutput>--cleanup=3Dyes</computeroutput> [default]</pa=
ra>
- <para><command>This is a flag to help debug valgrind itself.
- It is of no use to end-users.</command> When enabled, various
- improvments are applied to the post-instrumented intermediate
- code, aimed at removing redundant value checks.</para>
- </listitem>
-
</itemizedlist>
</sect1>
=20
|