Merge in the COMPVBITS branch to the trunk. This is a big change to
Memcheck, replacing the 9-bits-per-byte shadow memory representation to a
2-bits-per-byte representation (with possibly a little more on the side) by
taking advantage of the fact that extremely few memory bytes are partially
defined.
For the SPEC2k benchmarks with "test" inputs, this speeds up Memcheck by a
(geometric mean) factor of 1.20, and reduces the size of shadow memory by a
(geometric mean) factor of 4.26.
At the same time, Addrcheck is removed. It hadn't worked for quite some
time, and with these improvements in Memcheck its raisons-d'etre have
shrivelled so much that it's not worth the effort to keep around. Hooray!
Nb: this code hasn't been tested on PPC. If things go wrong, look first in
the fast stack-handling functions (eg. mc_new_mem_stack_160,
MC_(helperc_MAKE_STACK_UNINIT)).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5791 a5019735-40e9-0310-863c-91ae7b9d1cf9
diff --git a/docs/internals/xml-output.txt b/docs/internals/xml-output.txt
index 631c0d2..eaf16dc 100644
--- a/docs/internals/xml-output.txt
+++ b/docs/internals/xml-output.txt
@@ -34,7 +34,7 @@
caveats.
* At the present time only Memcheck is supported. The scheme extends
- easily enough to cover Addrcheck and Helgrind if needed.
+ easily enough to cover Helgrind if needed.
* When XML output is selected, various other settings are made.
This is in order that the output format is more controlled.
diff --git a/docs/xml/FAQ.xml b/docs/xml/FAQ.xml
index 915aede..04491db 100644
--- a/docs/xml/FAQ.xml
+++ b/docs/xml/FAQ.xml
@@ -159,7 +159,7 @@
<para>Another possibility is that your program has a bug and
erroneously jumps to a non-code address, in which case you'll get a
- SIGILL signal. Memcheck/Addrcheck may issue a warning just before
+ SIGILL signal. Memcheck may issue a warning just before
this happens, but they might not if the jump happens to land in
addressable memory.</para>
</answer>
@@ -470,7 +470,7 @@
<qandaentry id="faq.deflost">
<question id="q-deflost">
- <para>With Memcheck/Addrcheck's memory leak detector, what's the
+ <para>With Memcheck's memory leak detector, what's the
difference between "definitely lost", "possibly lost", "still
reachable", and "suppressed"?</para>
</question>
diff --git a/docs/xml/manual-core.xml b/docs/xml/manual-core.xml
index b6c56a0..5614be8 100644
--- a/docs/xml/manual-core.xml
+++ b/docs/xml/manual-core.xml
@@ -285,7 +285,7 @@
<sect1 id="manual-core.report" xreflabel="Reporting of errors">
<title>Reporting of errors</title>
-<para>When one of the error-checking tools (Memcheck, Addrcheck,
+<para>When one of the error-checking tools (Memcheck,
Helgrind) detects something bad happening in the program, an error
message is written to the commentary. For example:</para>
@@ -317,7 +317,7 @@
frequently.</para>
<para>Errors are reported before the associated operation actually
-happens. If you're using a tool (Memcheck, Addrcheck) which does
+happens. If you're using a tool (Memcheck) which does
address checking, and your program attempts to read from address zero,
the tool will emit a message to this effect, and the program will then
duly die with a segmentation fault.</para>
@@ -548,7 +548,7 @@
<listitem id="tool_name">
<para><option>--tool=<name></option> [default=memcheck]</para>
<para>Run the Valgrind tool called <emphasis>name</emphasis>,
- e.g. Memcheck, Addrcheck, Cachegrind, etc.</para>
+ e.g. Memcheck, Cachegrind, etc.</para>
</listitem>
</itemizedlist>
@@ -1025,7 +1025,7 @@
<!-- start of xi:include in the manpage -->
<para id="malloc-related.opts.para">For tools that use their own version of
<computeroutput>malloc()</computeroutput> (e.g. Memcheck and
-Addrcheck), the following options apply.</para>
+Massif), the following options apply.</para>
<variablelist id="malloc-related.opts.list">
@@ -1076,7 +1076,7 @@
a leak check is done at exit. In order to avoid this, they
provided a routine called <function>__libc_freeres</function>
specifically to make glibc release all memory it has allocated.
- Memcheck and Addrcheck therefore try and run
+ Memcheck therefore tries to run
<function>__libc_freeres</function> at exit.</para>
<para>Unfortunately, in some versions of glibc,
diff --git a/docs/xml/manual-intro.xml b/docs/xml/manual-intro.xml
index 35e4a85..a2058c9 100644
--- a/docs/xml/manual-intro.xml
+++ b/docs/xml/manual-intro.xml
@@ -64,35 +64,6 @@
</listitem>
<listitem>
- <para><command>Addrcheck</command> is a lightweight version of
- Memcheck. It is identical to Memcheck except for the single detail
- that it does not do any uninitialised-value checks. All of the
- other checks -- primarily the fine-grained address checking -- are
- still done. The downside of this is that you don't catch the
- uninitialised-value errors that Memcheck can find.</para>
-
- <para>But the upside is significant: programs run about twice as
- fast as they do on Memcheck, and a lot less memory is used. It
- still finds reads/writes of freed memory, memory off the end of
- blocks and in other invalid places, bugs which you really want to
- find before release!</para>
-
- <para>Because Addrcheck is lighter and faster than Memcheck, you can
- run more programs for longer, and so you may be able to cover more
- test scenarios. Addrcheck was created because one of us (Julian)
- wanted to be able to run a complete KDE desktop session with
- checking. As of early November 2002, we have been able to run
- KDE-3.0.3 on a 1.7 GHz P4 with 512 MB of memory, using Addrcheck.
- Although the result is not stellar, it's quite usable, and it seems
- plausible to run KDE for long periods at a time like this,
- collecting up all the addressing errors that appear.</para>
-
- <para>NOTE: Addrcheck is not available in Valgrind 3.1.X. We hope
- to reinstate its functionality in later releases. For now, use
- Memcheck instead.</para>
- </listitem>
-
- <listitem>
<para><command>Cachegrind</command> is a cache profiler. It
performs detailed simulation of the I1, D1 and L2 caches in your CPU
and so can accurately pinpoint the sources of cache misses in your
diff --git a/docs/xml/manual.xml b/docs/xml/manual.xml
index 0d99648..29f850d 100644
--- a/docs/xml/manual.xml
+++ b/docs/xml/manual.xml
@@ -24,8 +24,6 @@
xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="../../memcheck/docs/mc-manual.xml" parse="xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="../../addrcheck/docs/ac-manual.xml" parse="xml"
- xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="../../cachegrind/docs/cg-manual.xml" parse="xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="../../callgrind/docs/cl-manual.xml" parse="xml"
diff --git a/docs/xml/writing-tools.xml b/docs/xml/writing-tools.xml
index a9893b1..9fa3645 100644
--- a/docs/xml/writing-tools.xml
+++ b/docs/xml/writing-tools.xml
@@ -155,12 +155,6 @@
</listitem>
<listitem>
- <para><command>addrcheck</command>: performs lighterweight
- addressibility checks of every memory reference performed by
- the program.</para>
- </listitem>
-
- <listitem>
<para><command>cachegrind</command>: tracks every instruction
and memory reference to simulate instruction and data caches,
tracking cache accesses and misses that occur on every line in
@@ -547,10 +541,10 @@
to help understand something.</para>
<para>The <filename>pub_tool_*.h</filename> files have a reasonable
-amount of documentation in it that should hopefully be enough to get you
-going. But ultimately, the tools distributed (Memcheck, Addrcheck,
-Cachegrind, Lackey, etc.) are probably the best documentation of all,
-for the moment.</para>
+amount of documentation in it that should hopefully be enough to get
+you going. But ultimately, the tools distributed (Memcheck,
+Cachegrind, Lackey, etc.) are probably the best
+documentation of all, for the moment.</para>
<para>Note that the <computeroutput>VG_</computeroutput> macro is used
heavily. This just prepends a longer string in front of names to avoid