README_DEVELOPERS
(gdb) handle SIGILL SIGSEGV nostop noprint
(4) Set any breakpoints you want and proceed as normal for gdb. The
macro VG_(FUNC) is expanded to vgPlain_FUNC, so If you want to set
a breakpoint VG_(do_exec), you could do like this in GDB:
(gdb) b vgPlain_do_exec
(5) Run the tool with required options (the --tool option is required
for correct setup), e.g.
(gdb) run --tool=lackey pwd
Steps (1)--(3) can be put in a .gdbinit file, but any directory names must
be fully expanded (ie. not an environment variable).
A different and possibly easier way is as follows:
(1) Run Valgrind as normal, but add the flag --wait-for-gdb=yes.
This
puts the tool executable into a wait loop soon after it gains
control.
This delays startup for a few seconds.
(2) In a different shell, do "gdb /proc/<pid>/exe <pid>", where
<pid> you read from the output printed by (1).
This attaches
GDB to the tool executable, which should be in the abovementioned
wait loop.
(3) Do "cont" to continue.
After the loop finishes spinning, startup
will continue as normal.
Note that comment (3) above re passing
signals applies here too.
Self-hosting
~~~~~~~~~~~~
This section explains :
(A) How to configure Valgrind to run under Valgrind.
Such a setup is called self hosting, or outer/inner setup.
(B) How to run Valgrind regression tests in a ’self-hosting’ mode,
e.g. to verify Valgrind has no bugs such as memory leaks.
(C) How to run Valgrind performance tests in a ’self-hosting’ mode,
to analyse and optimise the performance of Valgrind and its tools.
(A) How to configure Valgrind to run under Valgrind:
(1) Check out 2 trees, "Inner" and "Outer".
Inner runs the app
directly.
Outer runs Inner.
(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
82