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 | e43d3ae | 2003-05-05 13:04:49 +0000 | [diff] [blame] | 4 | |
njn | 090dc84 | 2005-03-12 16:47:07 +0000 | [diff] [blame] | 5 | To run Valgrind without having to install it, run coregrind/valgrind |
sewardj | 45f4e7c | 2005-09-27 19:20:21 +0000 | [diff] [blame] | 6 | with the VALGRIND_LIB environment variable set, where <dir> is the root |
njn | 090dc84 | 2005-03-12 16:47:07 +0000 | [diff] [blame] | 7 | of the source tree (and must be an absolute path). Eg: |
| 8 | |
sewardj | 45f4e7c | 2005-09-27 19:20:21 +0000 | [diff] [blame] | 9 | VALGRIND_LIB=~/grind/head4/.in_place ~/grind/head4/coregrind/valgrind |
njn | e43d3ae | 2003-05-05 13:04:49 +0000 | [diff] [blame] | 10 | |
| 11 | This allows you to compile and run with "make" instead of "make install", |
| 12 | saving you time. |
| 13 | |
| 14 | I recommend compiling with "make --quiet" to further reduce the amount of |
| 15 | output spewed out during compilation, letting you actually see any errors, |
| 16 | warnings, etc. |
| 17 | |
| 18 | |
| 19 | Running the regression tests |
| 20 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 21 | To build and run all the regression tests, run "make [--quiet] regtest". |
| 22 | |
| 23 | To run a subset of the regression tests, execute: |
| 24 | |
| 25 | perl tests/vg_regtest <name> |
| 26 | |
| 27 | where <name> is a directory (all tests within will be run) or a single |
| 28 | .vgtest test file, or the name of a program which has a like-named .vgtest |
| 29 | file. Eg: |
| 30 | |
| 31 | perl tests/vg_regtest memcheck |
| 32 | perl tests/vg_regtest memcheck/tests/badfree.vgtest |
| 33 | perl tests/vg_regtest memcheck/tests/badfree |
| 34 | |
nethercote | 16b59ee | 2004-10-09 15:59:05 +0000 | [diff] [blame] | 35 | |
| 36 | Debugging Valgrind with GDB |
| 37 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
nethercote | 4fffabd | 2004-11-02 09:13:12 +0000 | [diff] [blame] | 38 | To debug stage 1 just run it under GDB in the normal way. |
| 39 | |
| 40 | To debug Valgrind proper (stage 2) with GDB, start Valgrind like this: |
nethercote | 16b59ee | 2004-10-09 15:59:05 +0000 | [diff] [blame] | 41 | |
| 42 | valgrind --tool=none --wait-for-gdb=yes <prog> |
| 43 | |
| 44 | Then start gdb like this in another terminal: |
| 45 | |
| 46 | gdb /usr/lib/valgrind/stage2 <pid> |
| 47 | |
| 48 | Where <pid> is the pid valgrind printed. Then set whatever breakpoints |
| 49 | you want and do this in gdb: |
| 50 | |
| 51 | jump *$eip |
| 52 | |
njn | 585b8b3 | 2005-10-10 11:36:55 +0000 | [diff] [blame] | 53 | |
| 54 | Self-hosting |
| 55 | ~~~~~~~~~~~~ |
| 56 | To run Valgrind under Valgrind: |
| 57 | |
| 58 | (1) Check out 2 trees, "inner" and "outer". "inner" runs the app |
| 59 | directly and is what you will be profiling. "outer" does the |
| 60 | profiling. |
| 61 | |
| 62 | (2) Configure inner with --enable-inner and build/install as |
| 63 | usual. |
| 64 | |
| 65 | (3) Configure outer normally and build/install as usual. |
| 66 | |
| 67 | (4) Choose a very simple program (date) and try |
| 68 | |
| 69 | outer/.../bin/valgrind --weird-hacks=enable-outer \ |
| 70 | --tool=cachegrind -v inner/.../bin/valgrind --tool=none -v prog |
| 71 | |
| 72 | It's fragile, confusing and slow, but it does work well enough for |
njn | 15a6563 | 2005-10-10 11:43:14 +0000 | [diff] [blame] | 73 | you to get some useful performance data. The inner Valgrind has most of |
| 74 | its output (ie. those lines beginning with "==<pid>==") prefixed with a |
| 75 | '>', which helps a lot. |
| 76 | |
| 77 | At the time of writing the allocator is not annotated with client requests |
| 78 | so Memcheck is not as useful as it could be. It also has not been tested |
| 79 | much, so don't be surprised if you hit problems. |
njn | 0dc09e8 | 2005-11-03 16:24:53 +0000 | [diff] [blame] | 80 | |
| 81 | Printing out problematic blocks |
| 82 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 83 | If you want to print out a disassembly of a particular block that |
| 84 | causes a crash, do the following. |
| 85 | |
| 86 | Try running with "--vex-guest-chase-thresh=0 --trace-flags=10000000 |
| 87 | --trace-notbelow=999999". This should print one line for each block |
| 88 | translated, and that includes the address. |
| 89 | |
| 90 | Then re-run with 999999 changed to the highest bb number shown. |
| 91 | This will print the one line per block, and also will print a |
| 92 | disassembly of the block in which the fault occurred. |