njn | e43d3ae | 2003-05-05 13:04:49 +0000 | [diff] [blame] | 1 | |
njn | e43d3ae | 2003-05-05 13:04:49 +0000 | [diff] [blame] | 2 | Building and not installing it |
| 3 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
njn | 090dc84 | 2005-03-12 16:47:07 +0000 | [diff] [blame] | 4 | To run Valgrind without having to install it, run coregrind/valgrind |
sewardj | 45f4e7c | 2005-09-27 19:20:21 +0000 | [diff] [blame] | 5 | with the VALGRIND_LIB environment variable set, where <dir> is the root |
njn | 090dc84 | 2005-03-12 16:47:07 +0000 | [diff] [blame] | 6 | of the source tree (and must be an absolute path). Eg: |
| 7 | |
sewardj | 45f4e7c | 2005-09-27 19:20:21 +0000 | [diff] [blame] | 8 | VALGRIND_LIB=~/grind/head4/.in_place ~/grind/head4/coregrind/valgrind |
njn | e43d3ae | 2003-05-05 13:04:49 +0000 | [diff] [blame] | 9 | |
| 10 | This allows you to compile and run with "make" instead of "make install", |
| 11 | saving you time. |
| 12 | |
njn | 7bbc8d6 | 2007-02-19 04:09:24 +0000 | [diff] [blame] | 13 | Or, you can use the 'vg-in-place' script which does that for you. |
| 14 | |
njn | e43d3ae | 2003-05-05 13:04:49 +0000 | [diff] [blame] | 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 | |
nethercote | 16b59ee | 2004-10-09 15:59:05 +0000 | [diff] [blame] | 36 | |
njn | 6f58249 | 2006-06-02 23:59:40 +0000 | [diff] [blame] | 37 | Running the performance tests |
njn | 5359b6f | 2006-06-02 23:57:22 +0000 | [diff] [blame] | 38 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
njn | 6f58249 | 2006-06-02 23:59:40 +0000 | [diff] [blame] | 39 | To build and run all the performance tests, run "make [--quiet] perf". |
njn | 5359b6f | 2006-06-02 23:57:22 +0000 | [diff] [blame] | 40 | |
njn | 6f58249 | 2006-06-02 23:59:40 +0000 | [diff] [blame] | 41 | To run a subset of the performance suite, execute: |
njn | 5359b6f | 2006-06-02 23:57:22 +0000 | [diff] [blame] | 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 | |
njn | 6f58249 | 2006-06-02 23:59:40 +0000 | [diff] [blame] | 53 | To compare multiple versions of Valgrind, use the --vg= option multiple |
njn | 5359b6f | 2006-06-02 23:57:22 +0000 | [diff] [blame] | 54 | times. For example, if you have two Valgrinds next to each other, one in |
njn | 6f58249 | 2006-06-02 23:59:40 +0000 | [diff] [blame] | 55 | trunk1/ and one in trunk2/, from within either trunk1/ or trunk2/ do this to |
| 56 | compare them on all the performance tests: |
njn | 5359b6f | 2006-06-02 23:57:22 +0000 | [diff] [blame] | 57 | |
| 58 | perl perf/vg_perf --vg=../trunk1 --vg=../trunk2 perf/ |
| 59 | |
| 60 | |
nethercote | 16b59ee | 2004-10-09 15:59:05 +0000 | [diff] [blame] | 61 | Debugging Valgrind with GDB |
| 62 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
tom | 4a5223b | 2005-11-17 12:31:12 +0000 | [diff] [blame] | 63 | To debug the valgrind launcher program (<prefix>/bin/valgrind) just |
| 64 | run it under gdb in the normal way. |
nethercote | 4fffabd | 2004-11-02 09:13:12 +0000 | [diff] [blame] | 65 | |
tom | 4a5223b | 2005-11-17 12:31:12 +0000 | [diff] [blame] | 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: |
nethercote | 16b59ee | 2004-10-09 15:59:05 +0000 | [diff] [blame] | 69 | |
njn | 90c8192 | 2007-09-17 22:35:57 +0000 | [diff] [blame] | 70 | (1) Set VALGRIND_LAUNCHER to point to the valgrind executable. Eg: |
nethercote | 16b59ee | 2004-10-09 15:59:05 +0000 | [diff] [blame] | 71 | |
njn | 90c8192 | 2007-09-17 22:35:57 +0000 | [diff] [blame] | 72 | export VALGRIND_LAUNCHER=/usr/local/bin/valgrind |
nethercote | 16b59ee | 2004-10-09 15:59:05 +0000 | [diff] [blame] | 73 | |
njn | 90c8192 | 2007-09-17 22:35:57 +0000 | [diff] [blame] | 74 | or for an uninstalled version in a source directory $DIR: |
nethercote | 16b59ee | 2004-10-09 15:59:05 +0000 | [diff] [blame] | 75 | |
njn | 90c8192 | 2007-09-17 22:35:57 +0000 | [diff] [blame] | 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 |
nethercote | 16b59ee | 2004-10-09 15:59:05 +0000 | [diff] [blame] | 85 | |
tom | 4a5223b | 2005-11-17 12:31:12 +0000 | [diff] [blame] | 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 |
nethercote | 16b59ee | 2004-10-09 15:59:05 +0000 | [diff] [blame] | 100 | |
njn | 90c8192 | 2007-09-17 22:35:57 +0000 | [diff] [blame] | 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). |
njn | 585b8b3 | 2005-10-10 11:36:55 +0000 | [diff] [blame] | 103 | |
njn | 4be4e2a | 2009-06-12 23:40:04 +0000 | [diff] [blame] | 104 | |
njn | 585b8b3 | 2005-10-10 11:36:55 +0000 | [diff] [blame] | 105 | Self-hosting |
| 106 | ~~~~~~~~~~~~ |
| 107 | To run Valgrind under Valgrind: |
| 108 | |
| 109 | (1) Check out 2 trees, "inner" and "outer". "inner" runs the app |
| 110 | directly and is what you will be profiling. "outer" does the |
| 111 | profiling. |
| 112 | |
| 113 | (2) Configure inner with --enable-inner and build/install as |
| 114 | usual. |
| 115 | |
| 116 | (3) Configure outer normally and build/install as usual. |
| 117 | |
| 118 | (4) Choose a very simple program (date) and try |
| 119 | |
njn | 86d6807 | 2005-11-12 19:07:45 +0000 | [diff] [blame] | 120 | outer/.../bin/valgrind --sim-hints=enable-outer --trace-children=yes \ |
njn | 585b8b3 | 2005-10-10 11:36:55 +0000 | [diff] [blame] | 121 | --tool=cachegrind -v inner/.../bin/valgrind --tool=none -v prog |
| 122 | |
njn | 7cce5b8 | 2005-11-16 20:12:22 +0000 | [diff] [blame] | 123 | If you omit the --trace-children=yes, you'll only monitor inner's launcher |
| 124 | program, not its stage2. |
| 125 | |
| 126 | The whole thing is fragile, confusing and slow, but it does work well enough |
| 127 | for you to get some useful performance data. The inner Valgrind has most of |
| 128 | its output (ie. those lines beginning with "==<pid>==") prefixed with a '>', |
| 129 | which helps a lot. |
njn | 15a6563 | 2005-10-10 11:43:14 +0000 | [diff] [blame] | 130 | |
| 131 | At the time of writing the allocator is not annotated with client requests |
| 132 | so Memcheck is not as useful as it could be. It also has not been tested |
| 133 | much, so don't be surprised if you hit problems. |
njn | 0dc09e8 | 2005-11-03 16:24:53 +0000 | [diff] [blame] | 134 | |
weidendo | 10e80e3 | 2006-05-01 01:49:28 +0000 | [diff] [blame] | 135 | When using self-hosting with an outer callgrind tool, use '--pop-on-jump' |
| 136 | (on the outer). Otherwise, callgrind has much higher memory requirements. |
| 137 | |
njn | 0b5efe7 | 2005-11-10 03:40:36 +0000 | [diff] [blame] | 138 | |
njn | 0dc09e8 | 2005-11-03 16:24:53 +0000 | [diff] [blame] | 139 | Printing out problematic blocks |
| 140 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 141 | If you want to print out a disassembly of a particular block that |
| 142 | causes a crash, do the following. |
| 143 | |
| 144 | Try running with "--vex-guest-chase-thresh=0 --trace-flags=10000000 |
| 145 | --trace-notbelow=999999". This should print one line for each block |
| 146 | translated, and that includes the address. |
| 147 | |
| 148 | Then re-run with 999999 changed to the highest bb number shown. |
| 149 | This will print the one line per block, and also will print a |
| 150 | disassembly of the block in which the fault occurred. |