1 2 Building and not installing it 3 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 4 To run Valgrind without having to install it, run coregrind/valgrind 5 with the VALGRIND_LIB environment variable set, where <dir> is the root 6 of the source tree (and must be an absolute path). Eg: 7 8 VALGRIND_LIB=~/grind/head4/.in_place ~/grind/head4/coregrind/valgrind 9 10 This allows you to compile and run with "make" instead of "make install", 11 saving you time. 12 13 Or, you can use the 'vg-in-place' script which does that for you. 14 15 I recommend compiling with "make --quiet" to further reduce the amount of 16 output spewed out during compilation, letting you actually see any errors, 17 warnings, etc. 18 19 20 Running the regression tests 21 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 22 To build and run all the regression tests, run "make [--quiet] regtest". 23 24 To run a subset of the regression tests, execute: 25 26 perl tests/vg_regtest <name> 27 28 where <name> is a directory (all tests within will be run) or a single 29 .vgtest test file, or the name of a program which has a like-named .vgtest 30 file. Eg: 31 32 perl tests/vg_regtest memcheck 33 perl tests/vg_regtest memcheck/tests/badfree.vgtest 34 perl tests/vg_regtest memcheck/tests/badfree 35 36 37 Running the performance tests 38 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 39 To build and run all the performance tests, run "make [--quiet] perf". 40 41 To run a subset of the performance suite, execute: 42 43 perl perf/vg_perf <name> 44 45 where <name> is a directory (all tests within will be run) or a single 46 .vgperf test file, or the name of a program which has a like-named .vgperf 47 file. Eg: 48 49 perl perf/vg_perf perf/ 50 perl perf/vg_perf perf/bz2.vgperf 51 perl perf/vg_perf perf/bz2 52 53 To compare multiple versions of Valgrind, use the --vg= option multiple 54 times. For example, if you have two Valgrinds next to each other, one in 55 trunk1/ and one in trunk2/, from within either trunk1/ or trunk2/ do this to 56 compare them on all the performance tests: 57 58 perl perf/vg_perf --vg=../trunk1 --vg=../trunk2 perf/ 59 60 61 Debugging Valgrind with GDB 62 ~~~~~~~~~~~~~~~~~~~~~~~~~~~ 63 To debug the valgrind launcher program (<prefix>/bin/valgrind) just 64 run it under gdb in the normal way. 65 66 Debugging the main body of the valgrind code (and/or the code for 67 a particular tool) requires a bit more trickery but can be achieved 68 without too much problem by following these steps: 69 70 (1) Set VALGRIND_LAUNCHER to point to the valgrind executable. Eg: 71 72 export VALGRIND_LAUNCHER=/usr/local/bin/valgrind 73 74 or for an uninstalled version in a source directory $DIR: 75 76 export VALGRIND_LAUNCHER=$DIR/coregrind/valgrind 77 78 (2) Run gdb on the tool executable. Eg: 79 80 gdb /usr/local/lib/valgrind/ppc32-linux/lackey 81 82 or 83 84 gdb $DIR/.in_place/x86-linux/memcheck 85 86 (3) Do "handle SIGSEGV SIGILL nostop noprint" in GDB to prevent GDB from 87 stopping on a SIGSEGV or SIGILL: 88 89 (gdb) handle SIGILL SIGSEGV nostop noprint 90 91 (4) Set any breakpoints you want and proceed as normal for gdb. The 92 macro VG_(FUNC) is expanded to vgPlain_FUNC, so If you want to set 93 a breakpoint VG_(do_exec), you could do like this in GDB: 94 95 (gdb) b vgPlain_do_exec 96 97 (5) Run the tool with required options: 98 99 (gdb) run pwd 100 101 Steps (1)--(3) can be put in a .gdbinit file, but any directory names must 102 be fully expanded (ie. not an environment variable). 103 104 A different and possibly easier way is as follows: 105 106 (1) Run Valgrind as normal, but add the flag --wait-for-gdb=yes. This 107 puts the tool executable into a wait loop soon after it gains 108 control. This delays startup for a few seconds. 109 110 (2) In a different shell, do "gdb /proc/<pid>/exe <pid>", where 111 <pid> you read from the output printed by (1). This attaches 112 GDB to the tool executable, which should be in the abovementioned 113 wait loop. 114 115 (3) Do "cont" to continue. After the loop finishes spinning, startup 116 will continue as normal. Note that comment (3) above re passing 117 signals applies here too. 118 119 120 Self-hosting 121 ~~~~~~~~~~~~ 122 To run Valgrind under Valgrind: 123 124 (1) Check out 2 trees, "Inner" and "Outer". Inner runs the app 125 directly. Outer runs Inner. 126 127 (2) Configure inner with --enable-inner and build/install as 128 usual. 129 130 (3) Configure Outer normally and build/install as usual. 131 132 (4) Choose a very simple program (date) and try 133 134 outer/.../bin/valgrind --sim-hints=enable-outer --trace-children=yes \ 135 --tool=cachegrind -v inner/.../bin/valgrind --tool=none -v prog 136 137 If you omit the --trace-children=yes, you'll only monitor Inner's launcher 138 program, not its stage2. 139 140 The whole thing is fragile, confusing and slow, but it does work well enough 141 for you to get some useful performance data. Inner has most of 142 its output (ie. those lines beginning with "==<pid>==") prefixed with a '>', 143 which helps a lot. 144 145 At the time of writing the allocator is not annotated with client requests 146 so Memcheck is not as useful as it could be. It also has not been tested 147 much, so don't be surprised if you hit problems. 148 149 When using self-hosting with an outer Callgrind tool, use '--pop-on-jump' 150 (on the outer). Otherwise, Callgrind has much higher memory requirements. 151 152 153 Printing out problematic blocks 154 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 155 If you want to print out a disassembly of a particular block that 156 causes a crash, do the following. 157 158 Try running with "--vex-guest-chase-thresh=0 --trace-flags=10000000 159 --trace-notbelow=999999". This should print one line for each block 160 translated, and that includes the address. 161 162 Then re-run with 999999 changed to the highest bb number shown. 163 This will print the one line per block, and also will print a 164 disassembly of the block in which the fault occurred. 165
