Tool writing documentation updates from Yao Qi <qiyaoltc@cn.ibm.com>.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4997 a5019735-40e9-0310-863c-91ae7b9d1cf9
diff --git a/docs/xml/writing-tools.xml b/docs/xml/writing-tools.xml
index 06a377f..a6ff41e 100644
--- a/docs/xml/writing-tools.xml
+++ b/docs/xml/writing-tools.xml
@@ -93,7 +93,7 @@
<para>A tool has no control over these operations; it never
"sees" the code doing this work and thus cannot instrument it.
However, the core provides hooks so a tool can be notified
- when certain interesting events happen, for example when when
+ when certain interesting events happen, for example when
dynamic memory is allocated or freed, the stack pointer is
changed, or a pthread mutex is locked, etc.</para>
@@ -181,7 +181,7 @@
(<computeroutput>_dl_runtime_resolve()</computeroutput>); the
number of basic blocks, x86 instruction, UCode instructions
executed; the number of branches executed and the proportion of
- those which were taken.</para>
+ them which were taken.</para>
</listitem>
</itemizedlist>
@@ -315,7 +315,8 @@
<para>To write your own tool, you'll need the Valgrind source code.
A normal source distribution should do, although you might want to
check out the latest code from the Subversion repository. See the
-information about how to do so at <ulink url="http://www.valgrind.org/">the
+information about how to do so at
+<ulink url="http://www.valgrind.org/downloads/repository.html">the
Valgrind website</ulink>.</para>
</sect2>
@@ -494,16 +495,15 @@
extra information about malloc'd blocks, etc.</para>
<para>For example, if a tool wants the core's help in recording
-and reporting errors, it must set the
-<computeroutput>tool_errors</computeroutput> need to
-<computeroutput>True</computeroutput>, and then provide
-definitions of six functions for comparing errors, printing out
+and reporting errors, it must call
+<computeroutput>VG_(needs_tool_errors)</computeroutput> and provide
+definitions of eight functions for comparing errors, printing out
errors, reading suppressions from a suppressions file, etc.
While writing these functions requires some work, it's much less
than doing error handling from scratch because the core is doing
-most of the work. See the type
-<computeroutput>VgNeeds</computeroutput> in
-<filename>include/tool.h</filename> for full details of all
+most of the work. See the function
+<computeroutput>VG_(needs_tool_errors)</computeroutput> in
+<filename>include/pub_tool_tooliface.h</filename> for full details of all
the needs.</para>
<para>Third, the tool can indicate which events in core it wants
@@ -523,7 +523,7 @@
<para>More information about "details", "needs" and "trackable
events" can be found in
-<filename>include/tool.h</filename>.</para>
+<filename>include/pub_tool_tooliface.h</filename>.</para>
</sect2>
@@ -688,8 +688,8 @@
<para>If you just want to know whether a program point has been
reached, using the <computeroutput>OINK</computeroutput> macro
-(in <filename>include/tool.h</filename>) can be easier than
-using GDB.</para>
+(in <filename>include/pub_tool_libcprint.h</filename>) can be easier
+than using GDB.</para>
<para>The other debugging command line options can be useful too
(run <computeroutput>valgrind -h</computeroutput> for the
@@ -808,7 +808,7 @@
</listitem>
<listitem>
- <para>Write the documentation. There are some helpful bits and
+ <para>Write the documentation. There are some helpful bits and
pieces on using xml markup in
<filename>valgrind/docs/xml/xml_help.txt</filename>.</para>
</listitem>
@@ -1124,8 +1124,8 @@
<computeroutput>VGP_POPCC</computeroutput> macros to record time
spent doing certain things. New profiling event numbers must not
overlap with the core profiling event numbers. See
-<filename>include/tool.h</filename> for details and Memcheck
-for an example.</para>
+<filename>include/pub_tool_profile.h</filename> for details and
+Memcheck for an example.</para>
</sect2>