Valgrind BBV, Быстрый старт

Страница: 191 / 319

Writing a New Valgrind Tool
In addition, if a tool wants to use some of the optional services provided by the core, it may have to define other
functions and tell the core about them.
2.2.5. Initialisation
Most of the initialisation should be done in pre_clo_init . Only use post_clo_init if a tool provides
command line options and must do some initialisation after option processing takes place (
"clo"
stands for
"command line options").
First of all, various "details" need to be set for a tool, using the functions
VG_(details_*)
. Some are all
compulsory, some aren’t. Some are used when constructing the startup message,
detail_bug_reports_to
is
used if
VG_(tool_panic)
is ever called, or a tool assertion fails. Others have other uses.
Second, various "needs" can be set for a tool, using the functions
VG_(needs_*)
. They are mostly booleans, and
can be left untouched (they default to
False
). They determine whether a tool can do various things such as: record,
report and suppress errors; process command line options; wrap system calls; record extra information about heap
blocks; etc.
For example, if a tool wants the core’s help in recording 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.
Third, the tool can indicate which events in core it wants to be notified about, using the functions
VG_(track_*)
.
These include things such as heap blocks being allocated, the stack pointer changing, a mutex being locked, etc. If a
tool wants to know about this, it should provide a pointer to a function, which will be called when that event happens.
For example, if the tool want to be notified when a new heap block is allocated, it should call
VG_(track_new_mem_heap)
with an appropriate function pointer, and the assigned function will be called each
time this happens.
More information about "details", "needs" and "trackable events" can be found in
include/pub_tool_tooliface.h
.
2.2.6. Instrumentation
instrument is the interesting one. It allows you to instrument VEX IR , which is Valgrind’s RISC-like intermediate
language. VEX IR is described in the comments of the header file VEX/pub/libvex_ir.h .
The easiest way to instrument VEX IR is to insert calls to C functions when interesting things happen. See the tool
"Lackey" (
lackey/lk_main.c
) for a simple example of this, or Cachegrind (
cachegrind/cg_main.c
) for a
more complex example.
2.2.7. Finalisation
This is where you can present the final results, such as a summary of the information collected. Any log files should
be written out at this point.
2.2.8. Other Important Information
Please note that the core/tool split infrastructure is quite complex and not brilliantly documented. Here are some
important points, but there are undoubtedly many others that I should note but haven’t thought of.
4