| Up to higher level directory | |||
| Name | Date | Size | |
|---|---|---|---|
| Android.build_all.mk | 03-Dec-2014 | 964 | |
| Android.build_one.mk | 03-Dec-2014 | 1.9K | |
| Android.clean.mk | 03-Dec-2014 | 900 | |
| Android.mk | 03-Dec-2014 | 16.9K | |
| Android.test.mk | 03-Dec-2014 | 159 | |
| AUTHORS | 03-Dec-2014 | 3.2K | |
| autogen.sh | 03-Dec-2014 | 191 | |
| auxprogs/ | 03-Dec-2014 | ||
| bionic.supp | 03-Dec-2014 | 1.3K | |
| cachegrind/ | 03-Dec-2014 | ||
| callgrind/ | 03-Dec-2014 | ||
| config.h | 03-Dec-2014 | 10.6K | |
| COPYING | 03-Dec-2014 | 17.6K | |
| COPYING.DOCS | 03-Dec-2014 | 19.9K | |
| coregrind/ | 03-Dec-2014 | ||
| darwin10-drd.supp | 03-Dec-2014 | 2.5K | |
| darwin10.supp | 03-Dec-2014 | 1.7K | |
| darwin11.supp | 03-Dec-2014 | 6.1K | |
| darwin12.supp | 03-Dec-2014 | 7.2K | |
| darwin9-drd.supp | 03-Dec-2014 | 10K | |
| darwin9.supp | 03-Dec-2014 | 7K | |
| docs/ | 03-Dec-2014 | ||
| drd/ | 03-Dec-2014 | ||
| exp-bbv/ | 03-Dec-2014 | ||
| exp-dhat/ | 03-Dec-2014 | ||
| exp-sgcheck/ | 03-Dec-2014 | ||
| exp-sgcheck.supp | 03-Dec-2014 | 372 | |
| gdbserver_tests/ | 03-Dec-2014 | ||
| glibc-2.2-LinuxThreads-helgrind.supp | 03-Dec-2014 | 1.2K | |
| glibc-2.2.supp | 03-Dec-2014 | 9.3K | |
| glibc-2.3.supp | 03-Dec-2014 | 11K | |
| glibc-2.34567-NPTL-helgrind.supp | 03-Dec-2014 | 5.8K | |
| glibc-2.4.supp | 03-Dec-2014 | 4.7K | |
| glibc-2.5.supp | 03-Dec-2014 | 3.8K | |
| glibc-2.6.supp | 03-Dec-2014 | 4.7K | |
| glibc-2.7.supp | 03-Dec-2014 | 695 | |
| glibc-2.X-drd.supp | 03-Dec-2014 | 6.6K | |
| glibc-2.X.supp | 03-Dec-2014 | 4.6K | |
| glibc-2.X.supp.in | 03-Dec-2014 | 5.2K | |
| helgrind/ | 03-Dec-2014 | ||
| include/ | 03-Dec-2014 | ||
| lackey/ | 03-Dec-2014 | ||
| Makefile.all.am | 03-Dec-2014 | 8.9K | |
| Makefile.am | 03-Dec-2014 | 3.3K | |
| Makefile.tool-tests.am | 03-Dec-2014 | 1.4K | |
| Makefile.tool.am | 03-Dec-2014 | 5.8K | |
| Makefile.vex.am | 03-Dec-2014 | 4.7K | |
| massif/ | 03-Dec-2014 | ||
| memcheck/ | 03-Dec-2014 | ||
| MODULE_LICENSE_GPL | 03-Dec-2014 | 0 | |
| mpi/ | 03-Dec-2014 | ||
| NEWS | 03-Dec-2014 | 109.4K | |
| NEWS.old | 03-Dec-2014 | 84.6K | |
| nightly/ | 03-Dec-2014 | ||
| none/ | 03-Dec-2014 | ||
| perf/ | 03-Dec-2014 | ||
| README | 03-Dec-2014 | 3.2K | |
| README.aarch64 | 03-Dec-2014 | 6.9K | |
| README.android | 03-Dec-2014 | 6.3K | |
| README.android_emulator | 03-Dec-2014 | 1.8K | |
| README.mips | 03-Dec-2014 | 2.2K | |
| README.s390 | 03-Dec-2014 | 1.9K | |
| README_DEVELOPERS | 03-Dec-2014 | 11.1K | |
| README_DEVELOPERS_processes | 03-Dec-2014 | 3.5K | |
| README_MISSING_SYSCALL_OR_IOCTL | 03-Dec-2014 | 6.8K | |
| README_PACKAGERS | 03-Dec-2014 | 4.4K | |
| shared/ | 03-Dec-2014 | ||
| tests/ | 03-Dec-2014 | ||
| valgrind.pc.in | 03-Dec-2014 | 447 | |
| valgrind.spec.in | 03-Dec-2014 | 1.2K | |
| VEX/ | 03-Dec-2014 | ||
| vg-in-place | 03-Dec-2014 | 691 | |
| xfree-3.supp | 03-Dec-2014 | 2.9K | |
| xfree-4.supp | 03-Dec-2014 | 8.8K | |
README
1 2 Release notes for Valgrind 3 ~~~~~~~~~~~~~~~~~~~~~~~~~~ 4 If you are building a binary package of Valgrind for distribution, 5 please read README_PACKAGERS. It contains some important information. 6 7 If you are developing Valgrind, please read README_DEVELOPERS. It contains 8 some useful information. 9 10 For instructions on how to build/install, see the end of this file. 11 12 If you have problems, consult the FAQ to see if there are workarounds. 13 14 15 Executive Summary 16 ~~~~~~~~~~~~~~~~~ 17 Valgrind is a framework for building dynamic analysis tools. There are 18 Valgrind tools that can automatically detect many memory management 19 and threading bugs, and profile your programs in detail. You can also 20 use Valgrind to build new tools. 21 22 The Valgrind distribution currently includes six production-quality 23 tools: a memory error detector, two thread error detectors, a cache 24 and branch-prediction profiler, a call-graph generating cache abd 25 branch-prediction profiler, and a heap profiler. It also includes 26 three experimental tools: a heap/stack/global array overrun detector, 27 a different kind of heap profiler, and a SimPoint basic block vector 28 generator. 29 30 Valgrind is closely tied to details of the CPU, operating system and to 31 a lesser extent, compiler and basic C libraries. This makes it difficult 32 to make it portable. Nonetheless, it is available for the following 33 platforms: 34 35 - X86/Linux 36 - AMD64/Linux 37 - PPC32/Linux 38 - PPC64/Linux 39 - ARM/Linux 40 - x86/MacOSX 41 - AMD64/MacOSX 42 - S390X/Linux 43 - MIPS32/Linux 44 - MIPS64/Linux 45 46 Note that AMD64 is just another name for x86_64, and Valgrind runs fine 47 on Intel processors. Also note that the core of MacOSX is called 48 "Darwin" and this name is used sometimes. 49 50 Valgrind is licensed under the GNU General Public License, version 2. 51 Read the file COPYING in the source distribution for details. 52 53 However: if you contribute code, you need to make it available as GPL 54 version 2 or later, and not 2-only. 55 56 57 Documentation 58 ~~~~~~~~~~~~~ 59 A comprehensive user guide is supplied. Point your browser at 60 $PREFIX/share/doc/valgrind/manual.html, where $PREFIX is whatever you 61 specified with --prefix= when building. 62 63 64 Building and installing it 65 ~~~~~~~~~~~~~~~~~~~~~~~~~~ 66 To install from the Subversion repository : 67 68 0. Check out the code from SVN, following the instructions at 69 http://www.valgrind.org/downloads/repository.html. 70 71 1. cd into the source directory. 72 73 2. Run ./autogen.sh to setup the environment (you need the standard 74 autoconf tools to do so). 75 76 3. Continue with the following instructions... 77 78 To install from a tar.bz2 distribution: 79 80 4. Run ./configure, with some options if you wish. The only interesting 81 one is the usual --prefix=/where/you/want/it/installed. 82 83 5. Run "make". 84 85 6. Run "make install", possibly as root if the destination permissions 86 require that. 87 88 7. See if it works. Try "valgrind ls -l". Either this works, or it 89 bombs out with some complaint. In that case, please let us know 90 (see www.valgrind.org). 91 92 Important! Do not move the valgrind installation into a place 93 different from that specified by --prefix at build time. This will 94 cause things to break in subtle ways, mostly when Valgrind handles 95 fork/exec calls. 96 97 98 The Valgrind Developers 99
README.aarch64
1 2 Status 3 ~~~~~~ 4 5 As of Jan 2014 the trunk contains a port to AArch64 ARMv8 -- loosely, 6 the 64-bit ARM architecture. Currently it supports integer and FP 7 instructions and can run anything generated by gcc-4.8.2 -O3. The 8 port is under active development. 9 10 Current limitations, as of mid-May 2014. 11 12 * limited support of vector (SIMD) instructions. Initial target is 13 support for instructions created by gcc-4.8.2 -O3 14 (via autovectorisation). This is complete. 15 16 * Integration with the built in GDB server: 17 - works ok (breakpoint, attach to a process blocked in a syscall, ...) 18 - still to do: 19 arm64 xml register description files (allowing shadow registers 20 to be looked at). 21 cpsr transfer to/from gdb to be looked at (see also arm equivalent code) 22 23 * limited syscall support 24 25 There has been extensive testing of the baseline simulation of integer 26 and FP instructions. Memcheck is also believed to work, at least for 27 small examples. Other tools appear to at least not crash when running 28 /bin/date. 29 30 Enough syscalls and instructions are supported for substantial 31 programs to work. Firefox 26 is able to start up and quit. The noise 32 level from Memcheck is low enough to make it practical to use for real 33 debugging. 34 35 36 Building 37 ~~~~~~~~ 38 39 You could probably build it directly on a target OS, using the normal 40 non-cross scheme 41 42 ./autogen.sh ; ./configure --prefix=.. ; make ; make install 43 44 Development so far was however done by cross compiling, viz: 45 46 export CC=aarch64-linux-gnu-gcc 47 export LD=aarch64-linux-gnu-ld 48 export AR=aarch64-linux-gnu-ar 49 50 ./autogen.sh 51 ./configure --prefix=`pwd`/Inst --host=aarch64-unknown-linux \ 52 --enable-only64bit 53 make -j4 54 make -j4 install 55 56 Doing this assumes that the install path (`pwd`/Inst) is valid on 57 both host and target, which isn't normally the case. To avoid 58 this limitation, do instead: 59 60 ./configure --prefix=/install/path/on/target \ 61 --host=aarch64-unknown-linux \ 62 --enable-only64bit 63 make -j4 64 make -j4 install DESTDIR=/a/temp/dir/on/host 65 # and then copy the contents of DESTDIR to the target. 66 67 See README.android for more examples of cross-compile building. 68 69 70 Implementation tidying-up/TODO notes 71 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 72 73 UnwindStartRegs -- what should that contain? 74 75 76 vki-arm64-linux.h: vki_sigaction_base 77 I really don't think that __vki_sigrestore_t sa_restorer 78 should be present. Adding it surely puts sa_mask at a wrong 79 offset compared to (kernel) reality. But not having it causes 80 compilation of m_signals.c to fail in hard to understand ways, 81 so adding it temporarily. 82 83 84 m_trampoline.S: what's the unexecutable-insn value? 0xFFFFFFFF 85 is there at the moment, but 0x00000000 is probably what it should be. 86 Also, fix indentation/tab-vs-space stuff 87 88 89 ./include/vki/vki-arm64-linux.h: uses __uint128_t. Should change 90 it to __vki_uint128_t, but what's the defn of that? 91 92 93 m_debuginfo/priv_storage.h: need proper defn of DiCfSI 94 95 96 readdwarf.c: is this correct? 97 #elif defined(VGP_arm64_linux) 98 # define FP_REG 29 //??? 99 # define SP_REG 31 //??? 100 # define RA_REG_DEFAULT 30 //??? 101 102 103 vki-arm64-linux.h: 104 re linux-3.10.5/include/uapi/asm-generic/sembuf.h 105 I'd say the amd64 version has padding it shouldn't have. Check? 106 107 108 syswrap-linux.c run_a_thread_NORETURN assembly sections 109 seems like tst->os_state.exitcode has word type 110 in which case the ppc64_linux use of lwz to read it, is wrong 111 112 113 syswrap-linux.c ML_(do_fork_clone) 114 assuming that VGP_arm64_linux is the same as VGP_arm_linux here 115 116 117 dispatch-arm64-linux.S: FIXME: set up FP control state before 118 entering generated code. Also fix screwy indentation. 119 120 121 dispatcher-ery general: what's a good (predictor-friendly) way to 122 branch to a register? 123 124 125 in vki-arm64-scnums.h 126 //#if __BITS_PER_LONG == 64 && !defined(__SYSCALL_COMPAT) 127 Probably want to reenable that and clean up accordingly 128 129 130 putIRegXXorZR: figure out a way that the computed value is actually 131 used, so as to keep any memory reads that might generate it, alive. 132 (else the simulation can lose exceptions). At least, for writes to 133 the zero register generated by loads .. or .. can anything other 134 integer instructions, that write to a register, cause exceptions? 135 136 137 loads/stores: generate stack alignment checks as necessary 138 139 140 fix barrier insns: ISB, DMB 141 142 143 fix atomic loads/stores 144 145 146 FMADD/FMSUB/FNMADD/FNMSUB: generate and use the relevant fused 147 IROps so as to avoid double rounding 148 149 150 ARM64Instr_Call getRegUsage: re-check relative to what 151 getAllocableRegs_ARM64 makes available 152 153 154 Make dispatch-arm64-linux.S save any callee-saved Q regs 155 I think what is required is to save D8-D15 and nothing more than that. 156 157 158 wrapper for __NR3264_fstat -- correct? 159 160 161 PRE(sys_clone): get rid of references to vki_modify_ldt_t and the 162 definition of it in vki-arm64-linux.h. Ditto for 32 bit arm. 163 164 165 sigframe-arm64-linux.c: build_sigframe: references to nonexistent 166 siguc->uc_mcontext.trap_no, siguc->uc_mcontext.error_code have been 167 replaced by zero. Also in synth_ucontext. 168 169 170 m_debugger.c: 171 uregs.pstate = LibVEX_GuestARM64_get_nzcv(vex); /* is this correct? */ 172 Is that remotely correct? 173 174 175 host_arm64_defs.c: emit_ARM64INstr: 176 ARM64in_VDfromX and ARM64in_VQfromXX: use simple top-half zeroing 177 MOVs to vector registers instead of INS Vd.D[0], Xreg, to avoid false 178 dependencies on the top half of the register. (Or at least check 179 the semantics of INS Vd.D[0] to see if it zeroes out the top.) 180 181 182 preferredVectorSubTypeFromSize: review perf effects and decide 183 on a types-for-subparts policy 184 185 186 fold_IRExpr_Unop: add a reduction rule for this 187 1Sto64(CmpNEZ64( Or64(GET:I64(1192),GET:I64(1184)) )) 188 vis 1Sto64(CmpNEZ64(x)) --> CmpwNEZ64(x) 189 190 191 check insn selection for memcheck-only primops: 192 Left64 CmpwNEZ64 V128to64 V128HIto64 1Sto64 CmpNEZ64 CmpNEZ32 193 widen_z_8_to_64 1Sto32 Left32 32HLto64 CmpwNEZ32 CmpNEZ8 194 195 196 isel: get rid of various cases where zero is put into a register 197 and just use xzr instead. Especially for CmpNEZ64/32. And for 198 writing zeroes into the CC thunk fields. 199 200 201 /* Keep this list in sync with that in iselNext below */ 202 /* Keep this list in sync with that for Ist_Exit above */ 203 uh .. they are not in sync 204 205 206 very stupid: 207 imm64 x23, 0xFFFFFFFFFFFFFFA0 208 17 F4 9F D2 F7 FF BF F2 F7 FF DF F2 F7 FF FF F2 209 210 211 valgrind.h: fix VALGRIND_ALIGN_STACK/VALGRIND_RESTORE_STACK, 212 also add CFI annotations 213 214 215 could possibly bring r29 into use, which be useful as it is 216 callee saved 217 218 219 ubfm/sbfm etc: special case cases that are simple shifts, as iropt 220 can't always simplify the general-case IR to a shift in such cases. 221 222 223 LDP,STP (immediate, simm7) (FP&VEC) 224 should zero out hi parts of dst registers in the LDP case 225 226 227 DUP insns: use Iop_Dup8x16, Iop_Dup16x8, Iop_Dup32x4 228 rather than doing it "by hand" 229 230 231 Any place where ZeroHI64ofV128 is used in conjunction with 232 FP vector IROps: find a way to make sure that arithmetic on 233 the upper half of the values is "harmless." 234 235 236 math_MINMAXV: use real Iop_Cat{Odd,Even}Lanes ops rather than 237 inline scalar code 238 239 240 chainXDirect_ARM64: use direct jump forms when possible 241
README.android
1 2 How to cross-compile for Android. These notes were last updated on 3 17 Feb 2012, for Valgrind SVN revision 12390/2257. 4 5 This is known to work at least for : 6 ARM: 7 Android 4.0.3 running on a (rooted, AOSP build) Nexus S. 8 Android 4.0.3 running on Motorola Xoom. 9 Android 4.0.3 running on android arm emulator. 10 Android 4.1 running on android emulator. 11 Android 2.3.4 on Nexus S worked at some time in the past. 12 13 x86: 14 Android 4.0.3 running on android x86 emulator. 15 16 mips32: 17 Android 4.1.2 running on android mips emulator. 18 Android 4.2.2 running on android mips emulator. 19 Android 4.3 running on android mips emulator. 20 Android 4.0.4 running on BROADCOM bcm7425 21 22 On android-arm, GDBserver might insert breaks at wrong addresses. 23 Feedback on this welcome. 24 25 Other configurations and toolchains might work, but haven't been tested. 26 Feedback is welcome. 27 28 29 You need the android-ndk-r6 native development kit. r6b and r7 30 give a non-completely-working build; see 31 http://code.google.com/p/android/issues/detail?id=23203 32 For the android emulator, the versions needed and how to 33 install them are described in README.android_emulator. 34 35 You can get android-ndk-r6 from 36 http://dl.google.com/android/ndk/android-ndk-r6-linux-x86.tar.bz2 37 Install it somewhere. Doesn't matter where. Then do this: 38 39 40 # Modify this (obviously). Note, this "export" command is only done 41 # so as to reduce the amount of typing required. None of the commands 42 # below read it as part of their operation. 43 # 44 export NDKROOT=/path/to/android-ndk-r6 45 46 47 # Modify this too. Tell the build system which Android hardware you 48 # are building for. It needs to know this so it can compile in 49 # support for the right Android-hw-specific ioctls. (sigh.) As with 50 # NDKROOT above, this is merely to avoid repeated typing; none of the 51 # commands read it. 52 # 53 # Currently the supported values are: nexus_s pandaboard 54 # So choose one of the below: 55 # 56 export HWKIND=nexus_s # Samsung Nexus S; also Xoom (for now) 57 export HWKIND=generic # A generic Android device. eg, Pandaboard 58 export HWKIND=emulator # Android emulator 59 60 # Then cd to the root of your Valgrind source tree. 61 # 62 cd /path/to/valgrind/source/tree 63 64 65 # After this point, you don't need to modify anything; just copy and 66 # paste the commands below. 67 68 69 # Set up toolchain paths. 70 # 71 # For ARM 72 export AR=$NDKROOT/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-ar 73 export LD=$NDKROOT/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-ld 74 export CC=$NDKROOT/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-gcc 75 76 # For x86 77 export AR=$NDKROOT/toolchains/x86-4.4.3/prebuilt/linux-x86/bin/i686-android-linux-ar 78 export LD=$NDKROOT/toolchains/x86-4.4.3/prebuilt/linux-x86/bin/i686-android-linux-ld 79 export CC=$NDKROOT/toolchains/x86-4.4.3/prebuilt/linux-x86/bin/i686-android-linux-gcc 80 81 # For MIPS32 82 export AR=$NDKROOT/toolchains/mipsel-linux-android-4.8/prebuilt/linux-x86_64/bin/mipsel-linux-android-ar 83 export LD=$NDKROOT/toolchains/mipsel-linux-android-4.8/prebuilt/linux-x86_64/bin/mipsel-linux-android-ld 84 export CC=$NDKROOT/toolchains/mipsel-linux-android-4.8/prebuilt/linux-x86_64/bin/mipsel-linux-android-gcc 85 86 # Do configuration stuff. Don't mess with the --prefix in the 87 # configure command below, even if you think it's wrong. 88 # You may need to set the --with-tmpdir path to something 89 # different if /sdcard doesn't work on the device -- this is 90 # a known cause of difficulties. 91 92 # The below re-generates configure, Makefiles, ... 93 # This is not needed if you start from a release tarball. 94 ./autogen.sh 95 96 # for ARM 97 CPPFLAGS="--sysroot=$NDKROOT/platforms/android-3/arch-arm -DANDROID_HARDWARE_$HWKIND" \ 98 CFLAGS="--sysroot=$NDKROOT/platforms/android-3/arch-arm" \ 99 ./configure --prefix=/data/local/Inst \ 100 --host=armv7-unknown-linux --target=armv7-unknown-linux \ 101 --with-tmpdir=/sdcard 102 # note: on android emulator, android-14 platform was also tested and works. 103 # It is not clear what this platform nr really is. 104 105 # for x86 106 CPPFLAGS="--sysroot=$NDKROOT/platforms/android-9/arch-x86 -DANDROID_HARDWARE_$HWKIND" \ 107 CFLAGS="--sysroot=$NDKROOT/platforms/android-9/arch-x86 -fno-pic" \ 108 ./configure --prefix=/data/local/Inst \ 109 --host=i686-android-linux --target=i686-android-linux \ 110 --with-tmpdir=/sdcard 111 112 # for MIPS32 113 CPPFLAGS="--sysroot=$NDKROOT/platforms/android-18/arch-mips -DANDROID_HARDWARE_$HWKIND" \ 114 CFLAGS="--sysroot=$NDKROOT/platforms/android-18/arch-mips" \ 115 ./configure --prefix=/data/local/Inst \ 116 --host=mipsel-linux-android --target=mipsel-linux-android \ 117 --with-tmpdir=/sdcard 118 119 # At the end of the configure run, a few lines of details 120 # are printed. Make sure that you see these two lines: 121 # 122 # For ARM: 123 # Platform variant: android 124 # Primary -DVGPV string: -DVGPV_arm_linux_android=1 125 # 126 # For x86: 127 # Platform variant: android 128 # Primary -DVGPV string: -DVGPV_x86_linux_android=1 129 # 130 # For mips32: 131 # Platform variant: android 132 # Primary -DVGPV string: -DVGPV_mips32_linux_android=1 133 # 134 # If you see anything else at this point, something is wrong, and 135 # either the build will fail, or will succeed but you'll get something 136 # which won't work. 137 138 139 # Build, and park the install tree in `pwd`/Inst 140 # 141 make -j2 142 make -j2 install DESTDIR=`pwd`/Inst 143 144 145 # To get the install tree onto the device: 146 # (I don't know why it's not "adb push Inst /data/local", but this 147 # formulation does appear to put the result in /data/local/Inst.) 148 # 149 adb push Inst / 150 151 # To run (on the device) 152 /data/local/Inst/bin/valgrind [the usual args etc] 153 154 155 # Once you're up and running, a handy modify-V-rebuild-reinstall 156 # command line (on the host, of course) is 157 # 158 mq -j2 && mq -j2 install DESTDIR=`pwd`/Inst && adb push Inst / 159 # 160 # where 'mq' is an alias for 'make --quiet'. 161 162 163 # One common cause of runs failing at startup is the inability of 164 # Valgrind to find a suitable temporary directory. On the device, 165 # there doesn't seem to be any one location which we always have 166 # permission to write to. The instructions above use /sdcard. If 167 # that doesn't work for you, and you're Valgrinding one specific 168 # application which is already installed, you could try using its 169 # temporary directory, in /data/data, for example 170 # /data/data/org.mozilla.firefox_beta. 171 # 172 # Using /system/bin/logcat on the device is helpful for diagnosing 173 # these kinds of problems. 174
README.android_emulator
1 2 How to install and run an android emulator. 3 4 mkdir android # or any other place you prefer 5 cd android 6 7 # download java JDK 8 # http://www.oracle.com/technetwork/java/javase/downloads/index.html 9 # download android SDK 10 # http://developer.android.com/sdk/index.html 11 # download android NDK 12 # http://developer.android.com/sdk/ndk/index.html 13 14 # versions I used: 15 # jdk-7u4-linux-i586.tar.gz 16 # android-ndk-r8-linux-x86.tar.bz2 17 # android-sdk_r18-linux.tgz 18 19 # install jdk 20 tar xzf jdk-7u4-linux-i586.tar.gz 21 22 # install sdk 23 tar xzf android-sdk_r18-linux.tgz 24 25 # install ndk 26 tar xjf android-ndk-r8-linux-x86.tar.bz2 27 28 29 # setup PATH to use the installed software: 30 export SDKROOT=$HOME/android/android-sdk-linux 31 export PATH=$PATH:$SDKROOT/tools:$SDKROOT/platform-tools 32 export NDKROOT=$HOME/android/android-ndk-r8 33 34 # install android platforms you want by starting: 35 android 36 # (from $SDKROOT/tools) 37 38 # select the platforms you need 39 # I selected and installed: 40 # Android 4.0.3 (API 15) 41 # Upgraded then to the newer version available: 42 # Android sdk 20 43 # Android platform tools 12 44 45 # then define a virtual device: 46 Tools -> Manage AVDs... 47 # I define an AVD Name with 64 Mb SD Card, (4.0.3, api 15) 48 # rest is default 49 50 51 # compile and make install Valgrind, following README.android 52 53 54 # Start your android emulator (it takes some time). 55 # You can use adb shell to get a shell on the device 56 # and see it is working. Note that I usually get 57 # one or two time out from adb shell before it works 58 adb shell 59 60 # Once the emulator is ready, push your Valgrind to the emulator: 61 adb push Inst / 62 63 64 # if you need to debug: 65 # You have on the android side a gdbserver 66 # on the device side: 67 gdbserver :1234 your_exe 68 69 # on the host side: 70 adb forward tcp:1234 tcp:1234 71 $HOME/android/android-ndk-r8/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-gdb your_exe 72 target remote :1234 73 74
README.mips
1 2 Supported platforms 3 ------------------- 4 - MIPS32 and MIPS64 platforms are currently supported. 5 - Both little-endian and big-endian cores are supported. 6 - MIPS DSP ASE on MIPS32 platforms is supported. 7 8 9 Building V for MIPS 10 ------------------- 11 - Native build is available for all supported platforms. The build system 12 expects that native GCC is configured correctly and optimized for the platform. 13 Yet, this may not be the case with some Debian distributions which configure 14 GCC to compile to "mips1" by default. Depending on a target platform, using 15 CFLAGS="-mips32r2", CFLAGS="-mips32" or CFLAGS="-mips64" or 16 CFLAGS="-mips64 -mabi=64" will do the trick and compile Valgrind correctly. 17 18 - Use of cross-toolchain is supported as well. 19 - Example of configure line and additional configure options: 20 21 $ ./configure --host=mipsel-linux-gnu --prefix=<path_to_install_directory> 22 [--with-pagesize=<4|16|64>] 23 24 * --host=mips-linux-gnu is necessary only if Valgrind is built on platform 25 other then MIPS, tools for building MIPS application have to be in PATH. 26 27 * --with-pagesize option is used to set default PAGE SIZE. If option is not 28 used, PAGE SIZE is set to value default for platform on which Valgrind is 29 built on. Possible values are 4, 16 of 64 and represent size in kilobytes. 30 31 * --host=mips-linux-gnu is necessary if you compile it with cross toolchain 32 compiler for big endian platform. 33 34 * --host=mipsel-linux-gnu is necessary if you compile it with cross toolchain 35 compiler for little endian platform. 36 37 * --build=mips-linux is needed if you want to build it for MIPS32 on 64-bit 38 MIPS system. 39 40 * If you are compiling Valgrind for mips32 with gcc version older then 41 gcc (GCC) 4.5.1, you must specify CFLAGS="-mips32r2 -mplt", e.g. 42 43 ./configure --prefix=<path_to_install_directory> 44 CFLAGS="-mips32r2 -mplt" 45 46 47 Limitations 48 ----------- 49 - Some gdb tests will fail when gdb (GDB) older than 7.5 is used and gdb is 50 not compiled with '--with-expat=yes'. 51 - You can not compile tests for DSP ASE if you are using gcc (GCC) older 52 then 4.6.1 due to a bug in the toolchain. 53 - Older GCC may have issues with some inline assembly blocks. Get a toolchain 54 based on newer GCC versions, if possible. 55
README.s390
1 2 Requirements 3 ------------ 4 - You need GCC 3.4 or later to compile the s390 port. 5 - To run valgrind a z10 machine or any later model is needed. 6 Older machine models down to and including z900 may work but have 7 not been tested extensively. 8 9 10 Limitations 11 ----------- 12 - 31-bit client programs are not supported. 13 - Hexadecimal floating point is not supported. 14 - memcheck, cachegrind, drd, helgrind, massif, lackey, and none are 15 supported. 16 - On machine models predating z10, cachegrind will assume a z10 cache 17 architecture. Otherwise, cachegrind will query the hosts cache system 18 and use those parameters. 19 - callgrind and all experimental tools are currently not supported. 20 - Some gcc versions use mvc to copy 4/8 byte values. This will affect 21 certain debug messages. For example, memcheck will complain about 22 4 one-byte reads/writes instead of just a single read/write. 23 24 25 Hardware facilities 26 ------------------- 27 Valgrind does not require that the host machine has the same hardware 28 facilities as the machine for which the client program was compiled. 29 This is convenient. The JIT compiler will translate the client instructions 30 according to the facilities available on the host. 31 This means, though, that probing for hardware facilities by issuing 32 instructions from that facility and observing whether SIGILL is thrown 33 may not work. As a consequence, programs that attempt to do so may 34 behave differently. It is believed that this is a rare use case. 35 36 37 Recommendations 38 --------------- 39 Applications should be compiled with -fno-builtin to avoid 40 false positives due to builtin string operations when running memcheck. 41 42 43 Reading Material 44 ---------------- 45 (1) Linux for zSeries ELF ABI Supplement 46 http://refspecs.linuxfoundation.org/ELF/zSeries/index.html 47 (2) z/Architecture Principles of Operation 48 http://publibfi.boulder.ibm.com/epubs/pdf/dz9zr009.pdf 49 (3) z/Architecture Reference Summary 50 http://publibfi.boulder.ibm.com/epubs/pdf/dz9zs007.pdf 51
README_DEVELOPERS
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 Building a distribution tarball 21 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 22 To build a distribution tarball from the valgrind sources: 23 24 make dist 25 26 In addition to compiling, linking and packaging everything up, the command 27 will also build the documentation. Even if all required tools for building the 28 documentation are installed, this step may not succeed because of hidden 29 dependencies. E.g. on Ubuntu you must have "docbook-xsl" installed. 30 Additionally, specific tool versions maybe needed. 31 32 If you only want to test whether the generated tarball is complete and runs 33 regression tests successfully, building documentation is not needed. 34 Edit docs/Makefile.am, search for BUILD_ALL_DOCS and follow instructions there. 35 36 37 Running the regression tests 38 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 39 To build and run all the regression tests, run "make [--quiet] regtest". 40 41 To run a subset of the regression tests, execute: 42 43 perl tests/vg_regtest <name> 44 45 where <name> is a directory (all tests within will be run) or a single 46 .vgtest test file, or the name of a program which has a like-named .vgtest 47 file. Eg: 48 49 perl tests/vg_regtest memcheck 50 perl tests/vg_regtest memcheck/tests/badfree.vgtest 51 perl tests/vg_regtest memcheck/tests/badfree 52 53 54 Running the performance tests 55 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 56 To build and run all the performance tests, run "make [--quiet] perf". 57 58 To run a subset of the performance suite, execute: 59 60 perl perf/vg_perf <name> 61 62 where <name> is a directory (all tests within will be run) or a single 63 .vgperf test file, or the name of a program which has a like-named .vgperf 64 file. Eg: 65 66 perl perf/vg_perf perf/ 67 perl perf/vg_perf perf/bz2.vgperf 68 perl perf/vg_perf perf/bz2 69 70 To compare multiple versions of Valgrind, use the --vg= option multiple 71 times. For example, if you have two Valgrinds next to each other, one in 72 trunk1/ and one in trunk2/, from within either trunk1/ or trunk2/ do this to 73 compare them on all the performance tests: 74 75 perl perf/vg_perf --vg=../trunk1 --vg=../trunk2 perf/ 76 77 78 Debugging Valgrind with GDB 79 ~~~~~~~~~~~~~~~~~~~~~~~~~~~ 80 To debug the valgrind launcher program (<prefix>/bin/valgrind) just 81 run it under gdb in the normal way. 82 83 Debugging the main body of the valgrind code (and/or the code for 84 a particular tool) requires a bit more trickery but can be achieved 85 without too much problem by following these steps: 86 87 (1) Set VALGRIND_LAUNCHER to point to the valgrind executable. Eg: 88 89 export VALGRIND_LAUNCHER=/usr/local/bin/valgrind 90 91 or for an uninstalled version in a source directory $DIR: 92 93 export VALGRIND_LAUNCHER=$DIR/coregrind/valgrind 94 95 (2) Run gdb on the tool executable. Eg: 96 97 gdb /usr/local/lib/valgrind/ppc32-linux/lackey 98 99 or 100 101 gdb $DIR/.in_place/x86-linux/memcheck 102 103 (3) Do "handle SIGSEGV SIGILL nostop noprint" in GDB to prevent GDB from 104 stopping on a SIGSEGV or SIGILL: 105 106 (gdb) handle SIGILL SIGSEGV nostop noprint 107 108 (4) Set any breakpoints you want and proceed as normal for gdb. The 109 macro VG_(FUNC) is expanded to vgPlain_FUNC, so If you want to set 110 a breakpoint VG_(do_exec), you could do like this in GDB: 111 112 (gdb) b vgPlain_do_exec 113 114 (5) Run the tool with required options (the --tool option is required 115 for correct setup), e.g. 116 117 (gdb) run --tool=lackey pwd 118 119 Steps (1)--(3) can be put in a .gdbinit file, but any directory names must 120 be fully expanded (ie. not an environment variable). 121 122 A different and possibly easier way is as follows: 123 124 (1) Run Valgrind as normal, but add the flag --wait-for-gdb=yes. This 125 puts the tool executable into a wait loop soon after it gains 126 control. This delays startup for a few seconds. 127 128 (2) In a different shell, do "gdb /proc/<pid>/exe <pid>", where 129 <pid> you read from the output printed by (1). This attaches 130 GDB to the tool executable, which should be in the abovementioned 131 wait loop. 132 133 (3) Do "cont" to continue. After the loop finishes spinning, startup 134 will continue as normal. Note that comment (3) above re passing 135 signals applies here too. 136 137 138 Self-hosting 139 ~~~~~~~~~~~~ 140 This section explains : 141 (A) How to configure Valgrind to run under Valgrind. 142 Such a setup is called self hosting, or outer/inner setup. 143 (B) How to run Valgrind regression tests in a 'self-hosting' mode, 144 e.g. to verify Valgrind has no bugs such as memory leaks. 145 (C) How to run Valgrind performance tests in a 'self-hosting' mode, 146 to analyse and optimise the performance of Valgrind and its tools. 147 148 (A) How to configure Valgrind to run under Valgrind: 149 150 (1) Check out 2 trees, "Inner" and "Outer". Inner runs the app 151 directly. Outer runs Inner. 152 153 (2) Configure inner with --enable-inner and build/install as usual. 154 155 (3) Configure Outer normally and build/install as usual. 156 157 (4) Choose a very simple program (date) and try 158 159 outer/.../bin/valgrind --sim-hints=enable-outer --trace-children=yes \ 160 --smc-check=all-non-file \ 161 --run-libc-freeres=no --tool=cachegrind -v \ 162 inner/.../bin/valgrind --vgdb-prefix=./inner --tool=none -v prog 163 164 Note: You must use a "make install"-ed valgrind. 165 Do *not* use vg-in-place for the outer valgrind. 166 167 If you omit the --trace-children=yes, you'll only monitor Inner's launcher 168 program, not its stage2. Outer needs --run-libc-freeres=no, as otherwise 169 it will try to find and run __libc_freeres in the inner, while libc is not 170 used by the inner. Inner needs --vgdb-prefix=./inner to avoid inner 171 gdbserver colliding with outer gdbserver. 172 Currently, inner does *not* use the client request 173 VALGRIND_DISCARD_TRANSLATIONS for the JITted code or the code patched for 174 translation chaining. So the outer needs --smc-check=all-non-file to 175 detect the modified code. 176 177 Debugging the whole thing might imply to use up to 3 GDB: 178 * a GDB attached to the Outer valgrind, allowing 179 to examine the state of Outer. 180 * a GDB using Outer gdbserver, allowing to 181 examine the state of Inner. 182 * a GDB using Inner gdbserver, allowing to 183 examine the state of prog. 184 185 The whole thing is fragile, confusing and slow, but it does work well enough 186 for you to get some useful performance data. Inner has most of 187 its output (ie. those lines beginning with "==<pid>==") prefixed with a '>', 188 which helps a lot. However, when running regression tests in an Outer/Inner 189 setup, this prefix causes the reg test diff to fail. Give 190 --sim-hints=no-inner-prefix to the Inner to disable the production 191 of the prefix in the stdout/stderr output of Inner. 192 193 The allocator (coregrind/m_mallocfree.c) is annotated with client requests 194 so Memcheck can be used to find leaks and use after free in an Inner 195 Valgrind. 196 197 The Valgrind "big lock" is annotated with helgrind client requests 198 so helgrind and drd can be used to find race conditions in an Inner 199 Valgrind. 200 201 All this has not been tested much, so don't be surprised if you hit problems. 202 203 When using self-hosting with an outer Callgrind tool, use '--pop-on-jump' 204 (on the outer). Otherwise, Callgrind has much higher memory requirements. 205 206 (B) Regression tests in an outer/inner setup: 207 208 To run all the regression tests with an outer memcheck, do : 209 perl tests/vg_regtest --outer-valgrind=../outer/.../bin/valgrind \ 210 --all 211 212 To run a specific regression tests with an outer memcheck, do: 213 perl tests/vg_regtest --outer-valgrind=../outer/.../bin/valgrind \ 214 none/tests/args.vgtest 215 216 To run regression tests with another outer tool: 217 perl tests/vg_regtest --outer-valgrind=../outer/.../bin/valgrind \ 218 --outer-tool=helgrind --all 219 220 --outer-args allows to give specific arguments to the outer tool, 221 replacing the default one provided by vg_regtest. 222 223 Note: --outer-valgrind must be a "make install"-ed valgrind. 224 Do *not* use vg-in-place. 225 226 When an outer valgrind runs an inner valgrind, a regression test 227 produces one additional file <testname>.outer.log which contains the 228 errors detected by the outer valgrind. E.g. for an outer memcheck, it 229 contains the leaks found in the inner, for an outer helgrind or drd, 230 it contains the detected race conditions. 231 232 The file tests/outer_inner.supp contains suppressions for 233 the irrelevant or benign errors found in the inner. 234 235 (C) Performance tests in an outer/inner setup: 236 237 To run all the performance tests with an outer cachegrind, do : 238 perl perf/vg_perf --outer-valgrind=../outer/.../bin/valgrind perf 239 240 To run a specific perf test (e.g. bz2) in this setup, do : 241 perl perf/vg_perf --outer-valgrind=../outer/.../bin/valgrind perf/bz2 242 243 To run all the performance tests with an outer callgrind, do : 244 perl perf/vg_perf --outer-valgrind=../outer/.../bin/valgrind \ 245 --outer-tool=callgrind perf 246 247 Note: --outer-valgrind must be a "make install"-ed valgrind. 248 Do *not* use vg-in-place. 249 250 To compare the performance of multiple Valgrind versions, do : 251 perl perf/vg_perf --outer-valgrind=../outer/.../bin/valgrind \ 252 --vg=../inner_xxxx --vg=../inner_yyyy perf 253 (where inner_xxxx and inner_yyyy are the toplevel directories of 254 the versions to compare). 255 Cachegrind and cg_diff are particularly handy to obtain a delta 256 between the two versions. 257 258 When the outer tool is callgrind or cachegrind, the following 259 output files will be created for each test: 260 <outertoolname>.out.<inner_valgrind_dir>.<tt>.<perftestname>.<pid> 261 <outertoolname>.outer.log.<inner_valgrind_dir>.<tt>.<perftestname>.<pid> 262 (where tt is the two letters abbreviation for the inner tool(s) run). 263 264 For example, the command 265 perl perf/vg_perf \ 266 --outer-valgrind=../outer_trunk/install/bin/valgrind \ 267 --outer-tool=callgrind \ 268 --vg=../inner_tchain --vg=../inner_trunk perf/many-loss-records 269 270 produces the files 271 callgrind.out.inner_tchain.no.many-loss-records.18465 272 callgrind.outer.log.inner_tchain.no.many-loss-records.18465 273 callgrind.out.inner_tchain.me.many-loss-records.21899 274 callgrind.outer.log.inner_tchain.me.many-loss-records.21899 275 callgrind.out.inner_trunk.no.many-loss-records.21224 276 callgrind.outer.log.inner_trunk.no.many-loss-records.21224 277 callgrind.out.inner_trunk.me.many-loss-records.22916 278 callgrind.outer.log.inner_trunk.me.many-loss-records.22916 279 280 281 Printing out problematic blocks 282 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 283 If you want to print out a disassembly of a particular block that 284 causes a crash, do the following. 285 286 Try running with "--vex-guest-chase-thresh=0 --trace-flags=10000000 287 --trace-notbelow=999999". This should print one line for each block 288 translated, and that includes the address. 289 290 Then re-run with 999999 changed to the highest bb number shown. 291 This will print the one line per block, and also will print a 292 disassembly of the block in which the fault occurred. 293
README_DEVELOPERS_processes
1 This file documents various "processes" that are used by Valgrind 2 developers for development and release activities. 3 This file contains one section for each process. 4 A summary of each process is given here. Each process is described 5 more in details afterwards. 6 7 8 * Update of the NEWS file: NEWS describes fixed bugs and new features. 9 It is updated and committed together with the code fixing the bug/implementing 10 the feature. 11 12 * Major release production: 13 See docs/internals/release-HOWTO.txt (currently a bit out of date) 14 15 * Minor/correction release production: TBD 16 17 18 Processes detailed descriptions: 19 20 Update of the NEWS file. 21 ======================== 22 The NEWS file gives for each release: 23 - the list of fixed bugs, 24 - a short description of each functional change, 25 - a short description of each technical change impacting the users. 26 27 The update of the NEWS file should be committed together with the 28 code change (or as part of the last committed change) that fixes the 29 bug or implements the new feature/technical change. 30 The documentation (e.g. user manual) should also be committed as part of 31 the code change. 32 33 Fixing a bug 34 ------------ 35 When fixing a bug, add a line in the 'FIXED BUGS' section of 36 the NEWS file. Keep the list of bugs sorted by bugzilla entry number. 37 38 Once you have commit the change, update the bug status in bugzilla, 39 adding in the comment the revision number of the commit fixing the bug. 40 41 If a bug is not entered in bugzilla (not encouraged), use "n-i-bz" 42 and add the bug line at the end of the bug list. 43 44 The file docs/internals/X_Y_BUGSTATUS.txt (where X_Y is the last 45 major release e.g. 3_9) contains information/statuses for some bugs. 46 If a bug is fixed, remove the (possible) bug info from this file. 47 48 Implementing a change 49 --------------------- 50 When implementing a functional or 'user impacting' technical change, 51 add a short description of the change in the relevant sub-section 52 (e.g. TOOL CHANGES, PLATFORM CHANGES, ...). 53 54 55 Some special cases: 56 ------------------- 57 Some bugs or changes only touch the VEX SVN repository, so it is not 58 possible to commit the NEWS change together with the code changes. 59 In such a case, first commit the VEX change. Then just after, commit 60 the NEWS change. In the bugzilla status, reference (at least) the Valgrind 61 revision number. 62 63 Some changes or bug fixes are very big and might be implemented over 64 a significant period. In such a case, update the NEWS as part of the 65 final commit. 66 If relevant, you might already update the NEWS file as part of 67 earlier commits, using the word 'PARTIAL' to indicate that the change or 68 bug fix is not complete yet. 69 70 Some bugs are reported more than once in bugzilla. 71 Also document in NEWS that such duplicated bugs have been fixed, using a line 72 such as: 73 308333 == 307106 74 to indicate that the bug 308333 is a duplicate of 307106, and was thus 75 fixed in the commit that fixed 307106. 76 Change also the status of the duplicated bug in bugzilla, 77 indicating in the comment the commit revision that fixed the 'master bug'. 78 79 80 81 Minor/correction release: 82 ========================= 83 Describe here how to do changes and bug fixed in a minor (correction) release 84 and how/when to merge the branch to the trunk. 85 86 Proposal to be discussed: 87 When a bug is fixed on the branch, the NEWS file is updated on the branch 88 (i.e. a 3.9.1 section is created if needed). 89 90 When often to merge the branch to trunk ? 91 after each fix ? 92 just after the correction release is produced ? 93 94 How is the branch merged to the trunk ? 95
README_MISSING_SYSCALL_OR_IOCTL
1 2 Dealing with missing system call or ioctl wrappers in Valgrind 3 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 4 You're probably reading this because Valgrind bombed out whilst 5 running your program, and advised you to read this file. The good 6 news is that, in general, it's easy to write the missing syscall or 7 ioctl wrappers you need, so that you can continue your debugging. If 8 you send the resulting patches to me, then you'll be doing a favour to 9 all future Valgrind users too. 10 11 Note that an "ioctl" is just a special kind of system call, really; so 12 there's not a lot of need to distinguish them (at least conceptually) 13 in the discussion that follows. 14 15 All this machinery is in coregrind/m_syswrap. 16 17 18 What are syscall/ioctl wrappers? What do they do? 19 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 20 Valgrind does what it does, in part, by keeping track of everything your 21 program does. When a system call happens, for example a request to read 22 part of a file, control passes to the Linux kernel, which fulfills the 23 request, and returns control to your program. The problem is that the 24 kernel will often change the status of some part of your program's memory 25 as a result, and tools (instrumentation plug-ins) may need to know about 26 this. 27 28 Syscall and ioctl wrappers have two jobs: 29 30 1. Tell a tool what's about to happen, before the syscall takes place. A 31 tool could perform checks beforehand, eg. if memory about to be written 32 is actually writeable. This part is useful, but not strictly 33 essential. 34 35 2. Tell a tool what just happened, after a syscall takes place. This is 36 so it can update its view of the program's state, eg. that memory has 37 just been written to. This step is essential. 38 39 The "happenings" mostly involve reading/writing of memory. 40 41 So, let's look at an example of a wrapper for a system call which 42 should be familiar to many Unix programmers. 43 44 45 The syscall wrapper for time() 46 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 47 The wrapper for the time system call looks like this: 48 49 PRE(sys_time) 50 { 51 /* time_t time(time_t *t); */ 52 PRINT("sys_time ( %p )",ARG1); 53 PRE_REG_READ1(long, "time", int *, t); 54 if (ARG1 != 0) { 55 PRE_MEM_WRITE( "time(t)", ARG1, sizeof(vki_time_t) ); 56 } 57 } 58 59 POST(sys_time) 60 { 61 if (ARG1 != 0) { 62 POST_MEM_WRITE( ARG1, sizeof(vki_time_t) ); 63 } 64 } 65 66 The first thing we do happens before the syscall occurs, in the PRE() function. 67 The PRE() function typically starts with invoking to the PRINT() macro. This 68 PRINT() macro implements support for the --trace-syscalls command line option. 69 Next, the tool is told the return type of the syscall, that the syscall has 70 one argument, the type of the syscall argument and that the argument is being 71 read from a register: 72 73 PRE_REG_READ1(long, "time", int *, t); 74 75 Next, if a non-NULL buffer is passed in as the argument, tell the tool that the 76 buffer is about to be written to: 77 78 if (ARG1 != 0) { 79 PRE_MEM_WRITE( "time", ARG1, sizeof(vki_time_t) ); 80 } 81 82 Finally, the really important bit, after the syscall occurs, in the POST() 83 function: if, and only if, the system call was successful, tell the tool that 84 the memory was written: 85 86 if (ARG1 != 0) { 87 POST_MEM_WRITE( ARG1, sizeof(vki_time_t) ); 88 } 89 90 The POST() function won't be called if the syscall failed, so you 91 don't need to worry about checking that in the POST() function. 92 (Note: this is sometimes a bug; some syscalls do return results when 93 they "fail" - for example, nanosleep returns the amount of unslept 94 time if interrupted. TODO: add another per-syscall flag for this 95 case.) 96 97 Note that we use the type 'vki_time_t'. This is a copy of the kernel 98 type, with 'vki_' prefixed. Our copies of such types are kept in the 99 appropriate vki*.h file(s). We don't include kernel headers or glibc headers 100 directly. 101 102 103 Writing your own syscall wrappers (see below for ioctl wrappers) 104 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 105 If Valgrind tells you that system call NNN is unimplemented, do the 106 following: 107 108 1. Find out the name of the system call: 109 110 grep NNN /usr/include/asm/unistd*.h 111 112 This should tell you something like __NR_mysyscallname. 113 Copy this entry to include/vki/vki-scnums-$(VG_PLATFORM).h. 114 115 116 2. Do 'man 2 mysyscallname' to get some idea of what the syscall 117 does. Note that the actual kernel interface can differ from this, 118 so you might also want to check a version of the Linux kernel 119 source. 120 121 NOTE: any syscall which has something to do with signals or 122 threads is probably "special", and needs more careful handling. 123 Post something to valgrind-developers if you aren't sure. 124 125 126 3. Add a case to the already-huge collection of wrappers in 127 the coregrind/m_syswrap/syswrap-*.c files. 128 For each in-memory parameter which is read or written by 129 the syscall, do one of 130 131 PRE_MEM_READ( ... ) 132 PRE_MEM_RASCIIZ( ... ) 133 PRE_MEM_WRITE( ... ) 134 135 for that parameter. Then do the syscall. Then, if the syscall 136 succeeds, issue suitable POST_MEM_WRITE( ... ) calls. 137 (There's no need for POST_MEM_READ calls.) 138 139 Also, add it to the syscall_table[] array; use one of GENX_, GENXY 140 LINX_, LINXY, PLAX_, PLAXY. 141 GEN* for generic syscalls (in syswrap-generic.c), LIN* for linux 142 specific ones (in syswrap-linux.c) and PLA* for the platform 143 dependant ones (in syswrap-$(PLATFORM)-linux.c). 144 The *XY variant if it requires a PRE() and POST() function, and 145 the *X_ variant if it only requires a PRE() 146 function. 147 148 If you find this difficult, read the wrappers for other syscalls 149 for ideas. A good tip is to look for the wrapper for a syscall 150 which has a similar behaviour to yours, and use it as a 151 starting point. 152 153 If you need structure definitions and/or constants for your syscall, 154 copy them from the kernel headers into include/vki.h and co., with 155 the appropriate vki_*/VKI_* name mangling. Don't #include any 156 kernel headers. And certainly don't #include any glibc headers. 157 158 Test it. 159 160 Note that a common error is to call POST_MEM_WRITE( ... ) 161 with 0 (NULL) as the first (address) argument. This usually means 162 your logic is slightly inadequate. It's a sufficiently common bug 163 that there's a built-in check for it, and you'll get a "probably 164 sanity check failure" for the syscall wrapper you just made, if this 165 is the case. 166 167 168 4. Once happy, send us the patch. Pretty please. 169 170 171 172 173 Writing your own ioctl wrappers 174 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 175 176 Is pretty much the same as writing syscall wrappers, except that all 177 the action happens within PRE(ioctl) and POST(ioctl). 178 179 There's a default case, sometimes it isn't correct and you have to write a 180 more specific case to get the right behaviour. 181 182 As above, please create a bug report and attach the patch as described 183 on http://www.valgrind.org. 184 185
README_PACKAGERS
1 2 Greetings, packaging person! This information is aimed at people 3 building binary distributions of Valgrind. 4 5 Thanks for taking the time and effort to make a binary distribution of 6 Valgrind. The following notes may save you some trouble. 7 8 9 -- Do not ship your Linux distro with a completely stripped 10 /lib/ld.so. At least leave the debugging symbol names on -- line 11 number info isn't necessary. If you don't want to leave symbols on 12 ld.so, alternatively you can have your distro install ld.so's 13 debuginfo package by default, or make ld.so.debuginfo be a 14 requirement of your Valgrind RPM/DEB/whatever. 15 16 Reason for this is that Valgrind's Memcheck tool needs to intercept 17 calls to, and provide replacements for, some symbols in ld.so at 18 startup (most importantly strlen). If it cannot do that, Memcheck 19 shows a large number of false positives due to the highly optimised 20 strlen (etc) routines in ld.so. This has caused some trouble in 21 the past. As of version 3.3.0, on some targets (ppc32-linux, 22 ppc64-linux), Memcheck will simply stop at startup (and print an 23 error message) if such symbols are not present, because it is 24 infeasible to continue. 25 26 It's not like this is going to cost you much space. We only need 27 the symbols for ld.so (a few K at most). Not the debug info and 28 not any debuginfo or extra symbols for any other libraries. 29 30 31 -- (Unfortunate but true) When you configure to build with the 32 --prefix=/foo/bar/xyzzy option, the prefix /foo/bar/xyzzy gets 33 baked into valgrind. The consequence is that you _must_ install 34 valgrind at the location specified in the prefix. If you don't, 35 it may appear to work, but will break doing some obscure things, 36 particularly doing fork() and exec(). 37 38 So you can't build a relocatable RPM / whatever from Valgrind. 39 40 41 -- Don't strip the debug info off lib/valgrind/$platform/vgpreload*.so 42 in the installation tree. Either Valgrind won't work at all, or it 43 will still work if you do, but will generate less helpful error 44 messages. Here's an example: 45 46 Mismatched free() / delete / delete [] 47 at 0x40043249: free (vg_clientfuncs.c:171) 48 by 0x4102BB4E: QGArray::~QGArray(void) (tools/qgarray.cpp:149) 49 by 0x4C261C41: PptDoc::~PptDoc(void) (include/qmemarray.h:60) 50 by 0x4C261F0E: PptXml::~PptXml(void) (pptxml.cc:44) 51 Address 0x4BB292A8 is 0 bytes inside a block of size 64 alloc'd 52 at 0x4004318C: __builtin_vec_new (vg_clientfuncs.c:152) 53 by 0x4C21BC15: KLaola::readSBStream(int) const (klaola.cc:314) 54 by 0x4C21C155: KLaola::stream(KLaola::OLENode const *) (klaola.cc:416) 55 by 0x4C21788F: OLEFilter::convert(QCString const &) (olefilter.cc:272) 56 57 This tells you that some memory allocated with new[] was freed with 58 free(). 59 60 Mismatched free() / delete / delete [] 61 at 0x40043249: (inside vgpreload_memcheck.so) 62 by 0x4102BB4E: QGArray::~QGArray(void) (tools/qgarray.cpp:149) 63 by 0x4C261C41: PptDoc::~PptDoc(void) (include/qmemarray.h:60) 64 by 0x4C261F0E: PptXml::~PptXml(void) (pptxml.cc:44) 65 Address 0x4BB292A8 is 0 bytes inside a block of size 64 alloc'd 66 at 0x4004318C: (inside vgpreload_memcheck.so) 67 by 0x4C21BC15: KLaola::readSBStream(int) const (klaola.cc:314) 68 by 0x4C21C155: KLaola::stream(KLaola::OLENode const *) (klaola.cc:416) 69 by 0x4C21788F: OLEFilter::convert(QCString const &) (olefilter.cc:272) 70 71 This isn't so helpful. Although you can tell there is a mismatch, 72 the names of the allocating and deallocating functions are no longer 73 visible. The same kind of thing occurs in various other messages 74 from valgrind. 75 76 77 -- Don't strip symbols from lib/valgrind/* in the installation tree. 78 Doing so will likely cause problems. Removing the line number info is 79 probably OK (at least for some of the files in that directory), although 80 that has not been tested by the Valgrind developers. 81 82 83 -- Please test the final installation works by running it on something 84 huge. I suggest checking that it can start and exit successfully 85 both Firefox and OpenOffice.org. I use these as test programs, and I 86 know they fairly thoroughly exercise Valgrind. The command lines to use 87 are: 88 89 valgrind -v --trace-children=yes firefox 90 91 valgrind -v --trace-children=yes soffice 92 93 94 If you find any more hints/tips for packaging, please report 95 it as a bugreport. See http://www.valgrind.org for details. 96
