Writing a New Valgrind Tool
8. When you have finished, try to generate PDF and PostScript output to check all is well, from within
docs/
:
make print-docs
Check the output
and
.ps
files in
docs/print/
.
Note that the toolchain is even more fragile for the print docs, so don’t feel too bad if you can’t get it working.
2.3.4. Regression Tests
Valgrind has some support for regression tests. If you want to write regression tests for your tool:
1. The tests go in
foobar/tests/
, which you will have created when you started writing the tool.
2. Write
foobar/tests/Makefile.am
. Use
memcheck/tests/Makefile.am
as an example.
3. Write the tests,
.vgtest
test description files,
.stdout.exp
and
.stderr.exp
expected output files. (Note
that Valgrind’s output goes to stderr.) Some details on writing and running tests are given in the comments at the
top of the testing script
tests/vg_regtest
.
4. Write a filter for stderr results
foobar/tests/filter_stderr
. It can call the existing filters in
tests/
.
See
memcheck/tests/filter_stderr
for an example; in particular note the
$dir
trick that ensures the
filter works correctly from any directory.
2.3.5. Profiling
Lots of profiling tools have trouble running Valgrind. For example, trying to use gprof is hopeless.
Probably the best way to profile a tool is with OProfile on Linux.
You can also use Cachegrind on it.
Read
README_DEVELOPERS
for details on running Valgrind under Valgrind;
it’s a bit fragile but can usually be made to work.
2.3.6. Other Makefile Hackery
If you add any directories under
foobar/
, you will need to add an appropriate
Makefile.am
to it, and add a
corresponding entry to the
AC_OUTPUT
list in
configure.in
.
If you add any scripts to your tool (see Cachegrind for an example) you need to add them to the
bin_SCRIPTS
variable in
foobar/Makefile.am
and possible also to the
AC_OUTPUT
list in
configure.in
.
2.3.7. The Core/tool Interface
The core/tool interface evolves over time, but it’s pretty stable. We deliberately do not provide backward compatibility
with old interfaces, because it is too difficult and too restrictive.
We view this as a good thing -- if we had to be
backward compatible with earlier versions, many improvements now in the system could not have been added.
Because tools are statically linked with the core, if a tool compiles successfully then it should be compatible with the
core.
We would not deliberately violate this property by, for example, changing the behaviour of a core function
without changing its prototype.
7
