From: Julian Seward <jseward@acm.org>
Date: Sun, 2 Dec 2007 02:01:09 +0000 (+0000)
Subject: * document gcc code generation shenanigans on ppc32-linux
X-Git-Tag: svn/VALGRIND_3_3_0~30
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=59b27169599fab4a2d5791ec1429c1a6958cd151;p=thirdparty%2Fvalgrind.git

* document gcc code generation shenanigans on ppc32-linux
* add docs for --malloc-fill and --free-fill


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

diff --git a/memcheck/docs/mc-manual.xml b/memcheck/docs/mc-manual.xml
index 3ddcc2bbd8..95707b5ac5 100644
--- a/memcheck/docs/mc-manual.xml
+++ b/memcheck/docs/mc-manual.xml
@@ -152,11 +152,19 @@ the following problems:</para>
       <para>When enabled, assume that reads and writes some small
       distance below the stack pointer are due to bugs in gcc 2.96, and
       does not report them.  The "small distance" is 256 bytes by
-      default.  Note that gcc 2.96 is the default compiler on some older
+      default.  Note that gcc 2.96 is the default compiler on some ancient
       Linux distributions (RedHat 7.X) and so you may need to use this
       flag.  Do not use it if you do not have to, as it can cause real
       errors to be overlooked.  A better alternative is to use a more
       recent gcc/g++ in which this bug is fixed.</para>
+
+      <para>You may also need to use this flag when working with
+      gcc/g++ 3.X or 4.X on 32-bit PowerPC Linux.  This is because
+      gcc/g++ generates code which occasionally accesses below the
+      stack pointer, particularly for floating-point to/from integer
+      conversions.  This is in violation of the 32-bit PowerPC ELF
+      specification, which makes no provision for locations below the
+      stack pointer to be accessible.</para>
     </listitem>
   </varlistentry>
 
@@ -199,6 +207,39 @@ the following problems:</para>
     </listitem>
   </varlistentry>
 
+  <varlistentry id="opt.malloc-fill" xreflabel="--malloc-fill">
+    <term>
+      <option><![CDATA[--malloc-fill=<hexnumber> ]]></option>
+    </term>
+    <listitem>
+      <para>Fills blocks allocated
+      by <computeroutput>malloc</computeroutput>,
+         <computeroutput>new</computeroutput>, etc, but not
+      by <computeroutput>calloc</computeroutput>, with the specified
+      byte.  This can be useful when trying to shake out obscure
+      memory corruption problems.  The allocated area is still
+      regarded by Memcheck as undefined -- this flag only affects its
+      contents.
+      </para>
+    </listitem>
+  </varlistentry>
+
+  <varlistentry id="opt.free-fill" xreflabel="--free-fill">
+    <term>
+      <option><![CDATA[--free-fill=<hexnumber> ]]></option>
+    </term>
+    <listitem>
+      <para>Fills blocks freed
+      by <computeroutput>free</computeroutput>,
+         <computeroutput>delete</computeroutput>, etc, with the
+      specified byte.  This can be useful when trying to shake out
+      obscure memory corruption problems.  The freed area is still
+      regarded by Memcheck as not valid for access -- this flag only
+      affects its contents.
+      </para>
+    </listitem>
+  </varlistentry>
+
 </variablelist>
 <!-- end of xi:include in the manpage -->