program with any extra supporting libraries.</para>
<para>The code added to your binary has negligible performance impact:
-on x86, amd64, ppc32 and ppc64, the overhead is 6 simple integer instructions
-and is probably undetectable except in tight loops.
-However, if you really wish to compile out the client requests, you can
-compile with <option>-DNVALGRIND</option> (analogous to
+on x86, amd64, ppc32, ppc64 and ARM, the overhead is 6 simple integer
+instructions and is probably undetectable except in tight loops.
+However, if you really wish to compile out the client requests, you
+can compile with <option>-DNVALGRIND</option> (analogous to
<option>-DNDEBUG</option>'s effect on
<function>assert</function>).
</para>
<para>
Alternatively, for transparent self-modifying-code support,
use<option>--smc-check=all</option>, or run
- on ppc32/Linux or ppc64/Linux.
+ on ppc32/Linux, ppc64/Linux or ARM/Linux.
</para>
</listitem>
</varlistentry>
</listitem>
</varlistentry>
+ <varlistentry>
+ <term><command><computeroutput>VALGRIND_RESIZEINPLACE_BLOCK</computeroutput>:</command></term>
+ <listitem>
+ <para>Informs a Valgrind tool that the size of an allocated block has been
+ modified but not its address. See <filename>valgrind.h</filename> for
+ more information on how to use it.</para>
+ </listitem>
+ </varlistentry>
+
<varlistentry>
<term>
<command><computeroutput>VALGRIND_CREATE_MEMPOOL</computeroutput></command>,
message is prefixed with the PID between a pair of
<computeroutput>**</computeroutput> markers. (Like all client requests,
nothing is output if the client program is not running under Valgrind.)
- Output is not produced until a newline is encountered, or subequent
+ Output is not produced until a newline is encountered, or subsequent
Valgrind output is printed; this allows you to build up a single line of
output over multiple calls. Returns the number of characters output,
excluding the PID prefix.</para>
<function>malloc</function> etc safely from within wrappers.
</para>
-<para>The above comments are true for {x86,amd64,ppc32}-linux. On
+<para>The above comments are true for {x86,amd64,ppc32,arm}-linux. On
ppc64-linux function wrapping is more fragile due to the (arguably
poorly designed) ppc64-linux ABI. This mandates the use of a shadow
stack which tracks entries/exits of both wrapper and replacement
possible to a limited depth, beyond which Valgrind has to abort the
run. This depth is currently 16 calls.</para>
-<para>For all platforms ({x86,amd64,ppc32,ppc64}-linux) all the above
+<para>For all platforms ({x86,amd64,ppc32,ppc64,arm}-linux) all the above
comments apply on a per-thread basis. In other words, wrapping is
thread-safe: each thread must individually observe the above
restrictions, but there is no need for any kind of inter-thread