2. Using and understanding the
Valgrind core
This chapter describes the Valgrind core services, command-line options and behaviours.
That means it is relevant
regardless of what particular tool you are using.
The information should be sufficient for you to make effective
day-to-day use of Valgrind. Advanced topics related to the Valgrind core are described in
Valgrind’s core: advanced
topics
.
A point of terminology: most references to "Valgrind" in this chapter refer to the Valgrind core services.
2.1. What Valgrind does with your program
Valgrind is designed to be as non-intrusive as possible. It works directly with existing executables. You don’t need to
recompile, relink, or otherwise modify the program to be checked.
You invoke Valgrind like this:
valgrind [valgrind-options] your-prog [your-prog-options]
The most important option is
--tool
which dictates which Valgrind tool to run.
For example, if want to run the
command
ls -l
using the memory-checking tool Memcheck, issue this command:
valgrind --tool=memcheck ls -l
However, Memcheck is the default, so if you want to use it you can omit the
--tool
option.
Regardless of which tool is in use, Valgrind takes control of your program before it starts. Debugging information is
read from the executable and associated libraries, so that error messages and other outputs can be phrased in terms of
source code locations, when appropriate.
Your program is then run on a synthetic CPU provided by the Valgrind core.
As new code is executed for the first
time, the core hands the code to the selected tool. The tool adds its own instrumentation code to this and hands the
result back to the core, which coordinates the continued execution of this instrumented code.
The amount of instrumentation code added varies widely between tools.
At one end of the scale, Memcheck adds
code to check every memory access and every value computed, making it run 10-50 times slower than natively. At the
other end of the spectrum, the minimal tool, called Nulgrind, adds no instrumentation at all and causes in total "only"
about a 4 times slowdown.
Valgrind simulates every single instruction your program executes. Because of this, the active tool checks, or profiles,
not only the code in your application but also in all supporting dynamically-linked libraries, including the C library,
graphical libraries, and so on.
If you’re using an error-detection tool, Valgrind may detect errors in system libraries, for example the GNU C or X11
libraries, which you have to use.
You might not be interested in these errors, since you probably have no control
over that code.
Therefore, Valgrind allows you to selectively suppress errors, by recording them in a suppressions
file which is read when Valgrind starts up. The build mechanism selects default suppressions which give reasonable
behaviour for the OS and libraries detected on your machine. To make it easier to write suppressions, you can use the
--gen-suppressions=yes
option. This tells Valgrind to print out a suppression for each reported error, which
you can then copy into a suppressions file.
3
