|Valgrind 3.3 - Advanced Debugging and Profiling for GNU/Linux applications|
by J. Seward, N. Nethercote, J. Weidendorfer and the Valgrind Development Team
Paperback (6"x9"), 164 pages
RRP £12.95 ($19.95)
3.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.
Simply put ‘valgrind --tool=tool_name’ at the start of the command line normally used to run the program. For example, if want to run the command ‘ls -l’ using the heavyweight memory-checking tool Memcheck, issue the command:
valgrind --tool=memcheck ls -l
Memcheck is the default, so if you want to use it you can
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 ultra-trivial
(also referred to as 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 (‘.so’-format) libraries, including the GNU C library, the X client libraries, Qt, if you work with KDE, and so on.
If you're using an error-detection tool, Valgrind may
detect errors in 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 attempts to select suppressions which give reasonable
behaviour for the C library
and X11 client library versions 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.
Different error-checking tools report different kinds of errors. The suppression mechanism therefore allows you to say which tool or tool(s) each suppression applies to.
|ISBN 0954612051||Valgrind 3.3 - Advanced Debugging and Profiling for GNU/Linux applications||See the print edition|