From: Tom Hughes Date: Fri, 4 Nov 2005 12:17:20 +0000 (+0000) Subject: Tool writing documentation updates from Yao Qi . X-Git-Tag: svn/VALGRIND_3_1_0~235 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=d827bf04098585c7364f4e0f1cf3ab2561808d38;p=thirdparty%2Fvalgrind.git Tool writing documentation updates from Yao Qi . git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4997 --- diff --git a/docs/xml/writing-tools.xml b/docs/xml/writing-tools.xml index 06a377f61c..a6ff41ec05 100644 --- a/docs/xml/writing-tools.xml +++ b/docs/xml/writing-tools.xml @@ -93,7 +93,7 @@ that there are three spaces in which program code executes: 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. @@ -181,7 +181,7 @@ interest? Consider some existing tools: (_dl_runtime_resolve()); the number of basic blocks, x86 instruction, UCode instructions executed; the number of branches executed and the proportion of - those which were taken. + them which were taken. @@ -315,7 +315,8 @@ memory checker. 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 the +information about how to do so at +the Valgrind website. @@ -494,16 +495,15 @@ errors; process command line options; wrap system calls; record extra information about malloc'd blocks, etc. For example, if a tool wants the core's help in recording -and reporting errors, it must set the -tool_errors need to -True, and then provide -definitions of six functions for comparing errors, printing out +and reporting errors, it must call +VG_(needs_tool_errors) 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 -VgNeeds in -include/tool.h for full details of all +most of the work. See the function +VG_(needs_tool_errors) in +include/pub_tool_tooliface.h for full details of all the needs. Third, the tool can indicate which events in core it wants @@ -523,7 +523,7 @@ be called each time this happens. More information about "details", "needs" and "trackable events" can be found in -include/tool.h. +include/pub_tool_tooliface.h. @@ -688,8 +688,8 @@ instrumentation. If you just want to know whether a program point has been reached, using the OINK macro -(in include/tool.h) can be easier than -using GDB. +(in include/pub_tool_libcprint.h) can be easier +than using GDB. The other debugging command line options can be useful too (run valgrind -h for the @@ -808,7 +808,7 @@ example tool name again): - Write the documentation. There are some helpful bits and + Write the documentation. There are some helpful bits and pieces on using xml markup in valgrind/docs/xml/xml_help.txt. @@ -1124,8 +1124,8 @@ and then use the VGP_PUSHCC and VGP_POPCC macros to record time spent doing certain things. New profiling event numbers must not overlap with the core profiling event numbers. See -include/tool.h for details and Memcheck -for an example. +include/pub_tool_profile.h for details and +Memcheck for an example.