mirror of
https://github.com/Zenithsiz/ftmemsim-valgrind.git
synced 2026-02-03 10:05:29 +00:00
80 lines
2.4 KiB
Plaintext
80 lines
2.4 KiB
Plaintext
|
|
Building and not installing it
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
To run Valgrind without having to install it, run coregrind/valgrind
|
|
with the VALGRIND_LIB environment variable set, where <dir> is the root
|
|
of the source tree (and must be an absolute path). Eg:
|
|
|
|
VALGRIND_LIB=~/grind/head4/.in_place ~/grind/head4/coregrind/valgrind
|
|
|
|
This allows you to compile and run with "make" instead of "make install",
|
|
saving you time.
|
|
|
|
I recommend compiling with "make --quiet" to further reduce the amount of
|
|
output spewed out during compilation, letting you actually see any errors,
|
|
warnings, etc.
|
|
|
|
|
|
Running the regression tests
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
To build and run all the regression tests, run "make [--quiet] regtest".
|
|
|
|
To run a subset of the regression tests, execute:
|
|
|
|
perl tests/vg_regtest <name>
|
|
|
|
where <name> is a directory (all tests within will be run) or a single
|
|
.vgtest test file, or the name of a program which has a like-named .vgtest
|
|
file. Eg:
|
|
|
|
perl tests/vg_regtest memcheck
|
|
perl tests/vg_regtest memcheck/tests/badfree.vgtest
|
|
perl tests/vg_regtest memcheck/tests/badfree
|
|
|
|
|
|
Debugging Valgrind with GDB
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
To debug stage 1 just run it under GDB in the normal way.
|
|
|
|
To debug Valgrind proper (stage 2) with GDB, start Valgrind like this:
|
|
|
|
valgrind --tool=none --wait-for-gdb=yes <prog>
|
|
|
|
Then start gdb like this in another terminal:
|
|
|
|
gdb /usr/lib/valgrind/stage2 <pid>
|
|
|
|
Where <pid> is the pid valgrind printed. Then set whatever breakpoints
|
|
you want and do this in gdb:
|
|
|
|
jump *$eip
|
|
|
|
|
|
Self-hosting
|
|
~~~~~~~~~~~~
|
|
To run Valgrind under Valgrind:
|
|
|
|
(1) Check out 2 trees, "inner" and "outer". "inner" runs the app
|
|
directly and is what you will be profiling. "outer" does the
|
|
profiling.
|
|
|
|
(2) Configure inner with --enable-inner and build/install as
|
|
usual.
|
|
|
|
(3) Configure outer normally and build/install as usual.
|
|
|
|
(4) Choose a very simple program (date) and try
|
|
|
|
outer/.../bin/valgrind --weird-hacks=enable-outer \
|
|
--tool=cachegrind -v inner/.../bin/valgrind --tool=none -v prog
|
|
|
|
It's fragile, confusing and slow, but it does work well enough for
|
|
you to get some useful performance data. The inner Valgrind has most of
|
|
its output (ie. those lines beginning with "==<pid>==") prefixed with a
|
|
'>', which helps a lot.
|
|
|
|
At the time of writing the allocator is not annotated with client requests
|
|
so Memcheck is not as useful as it could be. It also has not been tested
|
|
much, so don't be surprised if you hit problems.
|