NameDateSize

..12-Mar-20154 KiB

Android.build_all.mk12-Mar-2015964

Android.build_one.mk12-Mar-20151.9 KiB

Android.clean.mk12-Mar-2015900

Android.mk12-Mar-201516.9 KiB

Android.test.mk12-Mar-2015159

AUTHORS12-Mar-20153.2 KiB

autogen.sh12-Mar-2015191

auxprogs/12-Mar-20154 KiB

bionic.supp12-Mar-20151.3 KiB

cachegrind/12-Mar-20154 KiB

callgrind/12-Mar-20154 KiB

config.h12-Mar-201510.6 KiB

COPYING12-Mar-201517.6 KiB

COPYING.DOCS12-Mar-201519.9 KiB

coregrind/12-Mar-20154 KiB

darwin10-drd.supp12-Mar-20152.5 KiB

darwin10.supp12-Mar-20151.7 KiB

darwin11.supp12-Mar-20156.1 KiB

darwin12.supp12-Mar-20157.2 KiB

darwin9-drd.supp12-Mar-201510 KiB

darwin9.supp12-Mar-20157 KiB

docs/12-Mar-20154 KiB

drd/12-Mar-20154 KiB

exp-bbv/12-Mar-20154 KiB

exp-dhat/12-Mar-20154 KiB

exp-sgcheck/12-Mar-20154 KiB

exp-sgcheck.supp12-Mar-2015372

gdbserver_tests/12-Mar-201512 KiB

glibc-2.2-LinuxThreads-helgrind.supp12-Mar-20151.2 KiB

glibc-2.2.supp12-Mar-20159.3 KiB

glibc-2.3.supp12-Mar-201511 KiB

glibc-2.34567-NPTL-helgrind.supp12-Mar-20155.8 KiB

glibc-2.4.supp12-Mar-20154.7 KiB

glibc-2.5.supp12-Mar-20153.8 KiB

glibc-2.6.supp12-Mar-20154.7 KiB

glibc-2.7.supp12-Mar-2015695

glibc-2.X-drd.supp12-Mar-20156.6 KiB

glibc-2.X.supp12-Mar-20154.6 KiB

glibc-2.X.supp.in12-Mar-20155.2 KiB

helgrind/12-Mar-20154 KiB

include/12-Mar-20154 KiB

lackey/12-Mar-20154 KiB

Makefile.all.am12-Mar-20158.9 KiB

Makefile.am12-Mar-20153.3 KiB

Makefile.tool-tests.am12-Mar-20151.4 KiB

Makefile.tool.am12-Mar-20155.8 KiB

Makefile.vex.am12-Mar-20154.7 KiB

massif/12-Mar-20154 KiB

memcheck/12-Mar-20154 KiB

MODULE_LICENSE_GPL12-Mar-20150

mpi/12-Mar-20154 KiB

NEWS12-Mar-2015109.4 KiB

NEWS.old12-Mar-201584.6 KiB

nightly/12-Mar-20154 KiB

none/12-Mar-20154 KiB

perf/12-Mar-20154 KiB

README12-Mar-20153.2 KiB

README.aarch6412-Mar-20156.9 KiB

README.android12-Mar-20156.3 KiB

README.android_emulator12-Mar-20151.8 KiB

README.mips12-Mar-20152.2 KiB

README.s39012-Mar-20151.9 KiB

README_DEVELOPERS12-Mar-201511.1 KiB

README_DEVELOPERS_processes12-Mar-20153.5 KiB

README_MISSING_SYSCALL_OR_IOCTL12-Mar-20156.8 KiB

README_PACKAGERS12-Mar-20154.4 KiB

shared/12-Mar-20154 KiB

tests/12-Mar-20154 KiB

valgrind.pc.in12-Mar-2015447

valgrind.spec.in12-Mar-20151.2 KiB

VEX/12-Mar-20154 KiB

vg-in-place12-Mar-2015691

xfree-3.supp12-Mar-20152.9 KiB

xfree-4.supp12-Mar-20158.8 KiB

README

1
2Release notes for Valgrind
3~~~~~~~~~~~~~~~~~~~~~~~~~~
4If you are building a binary package of Valgrind for distribution,
5please read README_PACKAGERS.  It contains some important information.
6
7If you are developing Valgrind, please read README_DEVELOPERS.  It contains
8some useful information.
9
10For instructions on how to build/install, see the end of this file.
11
12If you have problems, consult the FAQ to see if there are workarounds.
13
14
15Executive Summary
16~~~~~~~~~~~~~~~~~
17Valgrind is a framework for building dynamic analysis tools. There are
18Valgrind tools that can automatically detect many memory management
19and threading bugs, and profile your programs in detail. You can also
20use Valgrind to build new tools.
21
22The Valgrind distribution currently includes six production-quality
23tools: a memory error detector, two thread error detectors, a cache
24and branch-prediction profiler, a call-graph generating cache abd
25branch-prediction profiler, and a heap profiler. It also includes
26three experimental tools: a heap/stack/global array overrun detector,
27a different kind of heap profiler, and a SimPoint basic block vector
28generator.
29
30Valgrind is closely tied to details of the CPU, operating system and to
31a lesser extent, compiler and basic C libraries. This makes it difficult
32to make it portable.  Nonetheless, it is available for the following
33platforms: 
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
46Note that AMD64 is just another name for x86_64, and Valgrind runs fine
47on Intel processors.  Also note that the core of MacOSX is called
48"Darwin" and this name is used sometimes.
49
50Valgrind is licensed under the GNU General Public License, version 2. 
51Read the file COPYING in the source distribution for details.
52
53However: if you contribute code, you need to make it available as GPL
54version 2 or later, and not 2-only.
55
56
57Documentation
58~~~~~~~~~~~~~
59A comprehensive user guide is supplied.  Point your browser at
60$PREFIX/share/doc/valgrind/manual.html, where $PREFIX is whatever you
61specified with --prefix= when building.
62
63
64Building and installing it
65~~~~~~~~~~~~~~~~~~~~~~~~~~
66To 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
78To 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
92Important!  Do not move the valgrind installation into a place
93different from that specified by --prefix at build time.  This will
94cause things to break in subtle ways, mostly when Valgrind handles
95fork/exec calls.
96
97
98The Valgrind Developers
99

README.aarch64

1
2Status
3~~~~~~
4
5As of Jan 2014 the trunk contains a port to AArch64 ARMv8 -- loosely,
6the 64-bit ARM architecture.  Currently it supports integer and FP
7instructions and can run anything generated by gcc-4.8.2 -O3.  The
8port is under active development.
9
10Current 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
25There has been extensive testing of the baseline simulation of integer
26and FP instructions.  Memcheck is also believed to work, at least for
27small examples.  Other tools appear to at least not crash when running
28/bin/date.
29
30Enough syscalls and instructions are supported for substantial
31programs to work.  Firefox 26 is able to start up and quit.  The noise
32level from Memcheck is low enough to make it practical to use for real
33debugging.
34
35
36Building
37~~~~~~~~
38
39You could probably build it directly on a target OS, using the normal
40non-cross scheme
41
42  ./autogen.sh ; ./configure --prefix=.. ; make ; make install
43
44Development 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
56Doing this assumes that the install path (`pwd`/Inst) is valid on
57both host and target, which isn't normally the case.  To avoid
58this 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
67See README.android for more examples of cross-compile building.
68
69
70Implementation tidying-up/TODO notes
71~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
72
73UnwindStartRegs -- what should that contain?
74
75
76vki-arm64-linux.h: vki_sigaction_base
77I really don't think that __vki_sigrestore_t sa_restorer
78should be present.  Adding it surely puts sa_mask at a wrong
79offset compared to (kernel) reality.  But not having it causes
80compilation of m_signals.c to fail in hard to understand ways,
81so adding it temporarily.
82
83
84m_trampoline.S: what's the unexecutable-insn value? 0xFFFFFFFF 
85is there at the moment, but 0x00000000 is probably what it should be.
86Also, fix indentation/tab-vs-space stuff
87
88
89./include/vki/vki-arm64-linux.h: uses __uint128_t.  Should change
90it to __vki_uint128_t, but what's the defn of that?
91
92
93m_debuginfo/priv_storage.h: need proper defn of DiCfSI
94
95
96readdwarf.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
103vki-arm64-linux.h:
104re linux-3.10.5/include/uapi/asm-generic/sembuf.h
105I'd say the amd64 version has padding it shouldn't have.  Check?
106
107
108syswrap-linux.c run_a_thread_NORETURN assembly sections
109seems like tst->os_state.exitcode has word type
110in which case the ppc64_linux use of lwz to read it, is wrong
111
112
113syswrap-linux.c ML_(do_fork_clone)
114assuming that VGP_arm64_linux is the same as VGP_arm_linux here
115
116
117dispatch-arm64-linux.S: FIXME: set up FP control state before
118entering generated code.  Also fix screwy indentation.
119
120
121dispatcher-ery general: what's a good (predictor-friendly) way to
122branch to a register?
123
124
125in vki-arm64-scnums.h
126//#if __BITS_PER_LONG == 64 && !defined(__SYSCALL_COMPAT)
127Probably want to reenable that and clean up accordingly
128
129
130putIRegXXorZR: figure out a way that the computed value is actually
131used, so as to keep any memory reads that might generate it, alive.
132(else the simulation can lose exceptions).  At least, for writes to
133the zero register generated by loads .. or .. can anything other
134integer instructions, that write to a register, cause exceptions?
135
136
137loads/stores: generate stack alignment checks as necessary
138
139
140fix barrier insns: ISB, DMB
141
142
143fix atomic loads/stores
144
145
146FMADD/FMSUB/FNMADD/FNMSUB: generate and use the relevant fused
147IROps so as to avoid double rounding
148
149
150ARM64Instr_Call getRegUsage: re-check relative to what
151getAllocableRegs_ARM64 makes available
152
153
154Make dispatch-arm64-linux.S save any callee-saved Q regs
155I think what is required is to save D8-D15 and nothing more than that.
156
157
158wrapper for __NR3264_fstat -- correct?
159
160
161PRE(sys_clone): get rid of references to vki_modify_ldt_t and the
162definition of it in vki-arm64-linux.h.  Ditto for 32 bit arm.
163
164
165sigframe-arm64-linux.c: build_sigframe: references to nonexistent
166siguc->uc_mcontext.trap_no, siguc->uc_mcontext.error_code have been
167replaced by zero.  Also in synth_ucontext.
168
169
170m_debugger.c:
171uregs.pstate   = LibVEX_GuestARM64_get_nzcv(vex); /* is this correct? */
172Is that remotely correct?
173
174
175host_arm64_defs.c: emit_ARM64INstr:
176ARM64in_VDfromX and ARM64in_VQfromXX: use simple top-half zeroing
177MOVs to vector registers instead of INS Vd.D[0], Xreg, to avoid false
178dependencies on the top half of the register.  (Or at least check
179the semantics of INS Vd.D[0] to see if it zeroes out the top.)
180
181
182preferredVectorSubTypeFromSize: review perf effects and decide
183on a types-for-subparts policy
184
185
186fold_IRExpr_Unop: add a reduction rule for this
1871Sto64(CmpNEZ64( Or64(GET:I64(1192),GET:I64(1184)) ))
188vis 1Sto64(CmpNEZ64(x)) --> CmpwNEZ64(x)
189
190
191check insn selection for memcheck-only primops:
192Left64 CmpwNEZ64 V128to64 V128HIto64 1Sto64 CmpNEZ64 CmpNEZ32
193widen_z_8_to_64 1Sto32 Left32 32HLto64 CmpwNEZ32 CmpNEZ8
194
195
196isel: get rid of various cases where zero is put into a register
197and just use xzr instead.  Especially for CmpNEZ64/32.  And for
198writing 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 */
203uh .. they are not in sync
204
205
206very stupid:
207imm64  x23, 0xFFFFFFFFFFFFFFA0
20817 F4 9F D2 F7 FF BF F2 F7 FF DF F2 F7 FF FF F2 
209
210
211valgrind.h: fix VALGRIND_ALIGN_STACK/VALGRIND_RESTORE_STACK,
212also add CFI annotations
213
214
215could possibly bring r29 into use, which be useful as it is
216callee saved
217
218
219ubfm/sbfm etc: special case cases that are simple shifts, as iropt
220can't always simplify the general-case IR to a shift in such cases.
221
222
223LDP,STP (immediate, simm7) (FP&VEC)
224should zero out hi parts of dst registers in the LDP case
225
226
227DUP insns: use Iop_Dup8x16, Iop_Dup16x8, Iop_Dup32x4
228rather than doing it "by hand"
229
230
231Any place where ZeroHI64ofV128 is used in conjunction with
232FP vector IROps: find a way to make sure that arithmetic on
233the upper half of the values is "harmless."
234
235
236math_MINMAXV: use real Iop_Cat{Odd,Even}Lanes ops rather than
237inline scalar code
238
239
240chainXDirect_ARM64: use direct jump forms when possible
241

README.android

1
2How to cross-compile for Android.  These notes were last updated on 
317 Feb 2012, for Valgrind SVN revision 12390/2257.
4
5This is known to work at least for :
6ARM:
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
13x86:
14  Android 4.0.3 running on android x86 emulator.
15
16mips32:
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
22On android-arm, GDBserver might insert breaks at wrong addresses.
23Feedback on this welcome.
24
25Other configurations and toolchains might work, but haven't been tested.
26Feedback is welcome.
27
28
29You need the android-ndk-r6 native development kit.  r6b and r7
30give a non-completely-working build; see
31http://code.google.com/p/android/issues/detail?id=23203
32For the android emulator, the versions needed and how to
33install them are described in README.android_emulator.
34
35You can get android-ndk-r6 from
36http://dl.google.com/android/ndk/android-ndk-r6-linux-x86.tar.bz2
37Install 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#
44export 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#
56export HWKIND=nexus_s         # Samsung Nexus S; also Xoom (for now)
57export HWKIND=generic         # A generic Android device. eg, Pandaboard
58export HWKIND=emulator        # Android emulator
59
60# Then cd to the root of your Valgrind source tree.
61#
62cd /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
72export AR=$NDKROOT/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-ar
73export LD=$NDKROOT/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-ld
74export CC=$NDKROOT/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-gcc
75
76# For x86
77export AR=$NDKROOT/toolchains/x86-4.4.3/prebuilt/linux-x86/bin/i686-android-linux-ar
78export LD=$NDKROOT/toolchains/x86-4.4.3/prebuilt/linux-x86/bin/i686-android-linux-ld
79export CC=$NDKROOT/toolchains/x86-4.4.3/prebuilt/linux-x86/bin/i686-android-linux-gcc
80
81# For MIPS32
82export AR=$NDKROOT/toolchains/mipsel-linux-android-4.8/prebuilt/linux-x86_64/bin/mipsel-linux-android-ar
83export LD=$NDKROOT/toolchains/mipsel-linux-android-4.8/prebuilt/linux-x86_64/bin/mipsel-linux-android-ld
84export 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
97CPPFLAGS="--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
106CPPFLAGS="--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
113CPPFLAGS="--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#
141make -j2
142make -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#
149adb 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#
158mq -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
2How to install and run an android emulator.
3
4mkdir android # or any other place you prefer
5cd 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
20tar xzf jdk-7u4-linux-i586.tar.gz
21
22# install sdk
23tar xzf android-sdk_r18-linux.tgz
24
25# install ndk
26tar xjf android-ndk-r8-linux-x86.tar.bz2
27
28
29# setup PATH to use the installed software:
30export SDKROOT=$HOME/android/android-sdk-linux
31export PATH=$PATH:$SDKROOT/tools:$SDKROOT/platform-tools
32export NDKROOT=$HOME/android/android-ndk-r8
33
34# install android platforms you want by starting:
35android 
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:
46Tools -> 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
58adb shell
59
60# Once the emulator is ready, push your Valgrind to the emulator:
61adb push Inst /
62
63
64# if you need to debug:
65# You have on the android side a gdbserver
66# on the device side:
67gdbserver :1234 your_exe
68
69# on the host side:
70adb 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
72target remote :1234
73
74

README.mips

1
2Supported 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
9Building V for MIPS
10-------------------
11- Native build is available for all supported platforms. The build system
12expects that native GCC is configured correctly and optimized for the platform.
13Yet, this may not be the case with some Debian distributions which configure
14GCC to compile to "mips1" by default. Depending on a target platform, using
15CFLAGS="-mips32r2", CFLAGS="-mips32" or CFLAGS="-mips64" or
16CFLAGS="-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
47Limitations
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
2Requirements
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
10Limitations
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
25Hardware facilities
26-------------------
27Valgrind does not require that the host machine has the same hardware
28facilities as the machine for which the client program was compiled.
29This is convenient. The JIT compiler will translate the client instructions
30according to the facilities available on the host.
31This means, though, that probing for hardware facilities by issuing
32instructions from that facility and observing whether SIGILL is thrown
33may not work. As a consequence, programs that attempt to do so may
34behave differently. It is believed that this is a rare use case.
35
36
37Recommendations
38---------------
39Applications should be compiled with -fno-builtin to avoid
40false positives due to builtin string operations when running memcheck.
41
42
43Reading 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
2Building and not installing it
3~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4To run Valgrind without having to install it, run coregrind/valgrind
5with the VALGRIND_LIB environment variable set, where <dir> is the root
6of the source tree (and must be an absolute path).  Eg:
7
8  VALGRIND_LIB=~/grind/head4/.in_place ~/grind/head4/coregrind/valgrind 
9
10This allows you to compile and run with "make" instead of "make install",
11saving you time.
12
13Or, you can use the 'vg-in-place' script which does that for you.
14
15I recommend compiling with "make --quiet" to further reduce the amount of
16output spewed out during compilation, letting you actually see any errors,
17warnings, etc.
18
19
20Building a distribution tarball
21~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
22To build a distribution tarball from the valgrind sources:
23
24  make dist
25
26In addition to compiling, linking and packaging everything up, the command
27will also build the documentation. Even if all required tools for building the
28documentation are installed, this step may not succeed because of hidden
29dependencies. E.g. on Ubuntu you must have "docbook-xsl" installed.
30Additionally, specific tool versions maybe needed.
31
32If you only want to test whether the generated tarball is complete and runs
33regression tests successfully, building documentation is not needed.
34Edit docs/Makefile.am, search for BUILD_ALL_DOCS and follow instructions there.
35
36
37Running the regression tests
38~~~~~~~~~~~~~~~~~~~~~~~~~~~~
39To build and run all the regression tests, run "make [--quiet] regtest".
40
41To run a subset of the regression tests, execute:
42
43  perl tests/vg_regtest <name>
44
45where <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
47file.  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
54Running the performance tests
55~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
56To build and run all the performance tests, run "make [--quiet] perf".
57
58To run a subset of the performance suite, execute:
59
60  perl perf/vg_perf <name>
61
62where <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
64file.  Eg:
65
66  perl perf/vg_perf perf/
67  perl perf/vg_perf perf/bz2.vgperf
68  perl perf/vg_perf perf/bz2
69
70To compare multiple versions of Valgrind, use the --vg= option multiple
71times.  For example, if you have two Valgrinds next to each other, one in
72trunk1/ and one in trunk2/, from within either trunk1/ or trunk2/ do this to
73compare them on all the performance tests:
74
75  perl perf/vg_perf --vg=../trunk1 --vg=../trunk2 perf/
76
77
78Debugging Valgrind with GDB
79~~~~~~~~~~~~~~~~~~~~~~~~~~~
80To debug the valgrind launcher program (<prefix>/bin/valgrind) just
81run it under gdb in the normal way.
82
83Debugging the main body of the valgrind code (and/or the code for
84a particular tool) requires a bit more trickery but can be achieved
85without 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
119Steps (1)--(3) can be put in a .gdbinit file, but any directory names must
120be fully expanded (ie. not an environment variable).
121
122A 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
138Self-hosting
139~~~~~~~~~~~~
140This 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
164Note: You must use a "make install"-ed valgrind.
165Do *not* use vg-in-place for the outer valgrind.
166
167If you omit the --trace-children=yes, you'll only monitor Inner's launcher
168program, not its stage2. Outer needs --run-libc-freeres=no, as otherwise
169it will try to find and run __libc_freeres in the inner, while libc is not
170used by the inner. Inner needs --vgdb-prefix=./inner to avoid inner
171gdbserver colliding with outer gdbserver.
172Currently, inner does *not* use the client request 
173VALGRIND_DISCARD_TRANSLATIONS for the JITted code or the code patched for
174translation chaining. So the outer needs --smc-check=all-non-file to
175detect the modified code.
176
177Debugging 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
185The whole thing is fragile, confusing and slow, but it does work well enough
186for you to get some useful performance data.  Inner has most of
187its output (ie. those lines beginning with "==<pid>==") prefixed with a '>',
188which helps a lot. However, when running regression tests in an Outer/Inner
189setup, this prefix causes the reg test diff to fail. Give 
190--sim-hints=no-inner-prefix to the Inner to disable the production
191of the prefix in the stdout/stderr output of Inner.
192
193The allocator (coregrind/m_mallocfree.c) is annotated with client requests
194so Memcheck can be used to find leaks and use after free in an Inner
195Valgrind.
196
197The Valgrind "big lock" is annotated with helgrind client requests
198so helgrind and drd can be used to find race conditions in an Inner
199Valgrind.
200
201All this has not been tested much, so don't be surprised if you hit problems.
202
203When 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
223Note: --outer-valgrind must be a "make install"-ed valgrind.
224Do *not* use vg-in-place.
225
226When an outer valgrind runs an inner valgrind, a regression test
227produces one additional file <testname>.outer.log which contains the
228errors detected by the outer valgrind.  E.g. for an outer memcheck, it
229contains the leaks found in the inner, for an outer helgrind or drd,
230it contains the detected race conditions.
231
232The file tests/outer_inner.supp contains suppressions for 
233the 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
247Note: --outer-valgrind must be a "make install"-ed valgrind.
248Do *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
258When the outer tool is callgrind or cachegrind, the following
259output 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
264For 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
270produces 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
281Printing out problematic blocks
282~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
283If you want to print out a disassembly of a particular block that
284causes a crash, do the following.
285
286Try running with "--vex-guest-chase-thresh=0 --trace-flags=10000000
287--trace-notbelow=999999".  This should print one line for each block
288translated, and that includes the address.
289
290Then re-run with 999999 changed to the highest bb number shown.
291This will print the one line per block, and also will print a
292disassembly of the block in which the fault occurred.
293

README_DEVELOPERS_processes

1This file documents various "processes" that are used by Valgrind
2developers for development and release activities.
3This file contains one section for each process.
4A summary of each process is given here. Each process is described
5more 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
18Processes detailed descriptions:
19
20Update 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
81Minor/correction release:
82=========================
83Describe here how to do changes and bug fixed in a minor (correction) release
84and how/when to merge the branch to the trunk.
85
86Proposal to be discussed:
87When 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
90When often to merge the branch to trunk ?
91  after each fix ?
92  just after the correction release is produced ?
93
94How is the branch merged to the trunk ?
95

README_MISSING_SYSCALL_OR_IOCTL

1
2Dealing with missing system call or ioctl wrappers in Valgrind
3~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4You're probably reading this because Valgrind bombed out whilst
5running your program, and advised you to read this file.  The good
6news is that, in general, it's easy to write the missing syscall or
7ioctl wrappers you need, so that you can continue your debugging.  If
8you send the resulting patches to me, then you'll be doing a favour to
9all future Valgrind users too.
10
11Note that an "ioctl" is just a special kind of system call, really; so
12there's not a lot of need to distinguish them (at least conceptually)
13in the discussion that follows.
14
15All this machinery is in coregrind/m_syswrap.
16
17
18What are syscall/ioctl wrappers?  What do they do?
19~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
20Valgrind does what it does, in part, by keeping track of everything your
21program does.  When a system call happens, for example a request to read
22part of a file, control passes to the Linux kernel, which fulfills the
23request, and returns control to your program.  The problem is that the
24kernel will often change the status of some part of your program's memory
25as a result, and tools (instrumentation plug-ins) may need to know about
26this.
27
28Syscall and ioctl wrappers have two jobs: 
29
301. 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
352. 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
39The "happenings" mostly involve reading/writing of memory.
40
41So, let's look at an example of a wrapper for a system call which
42should be familiar to many Unix programmers.
43
44
45The syscall wrapper for time()
46~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
47The 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
66The first thing we do happens before the syscall occurs, in the PRE() function.
67The PRE() function typically starts with invoking to the PRINT() macro. This
68PRINT() macro implements support for the --trace-syscalls command line option.
69Next, the tool is told the return type of the syscall, that the syscall has
70one argument, the type of the syscall argument and that the argument is being
71read from a register:
72
73     PRE_REG_READ1(long, "time", int *, t);
74
75Next, if a non-NULL buffer is passed in as the argument, tell the tool that the
76buffer is about to be written to:
77
78     if (ARG1 != 0) {
79        PRE_MEM_WRITE( "time", ARG1, sizeof(vki_time_t) );
80     }
81
82Finally, the really important bit, after the syscall occurs, in the POST()
83function:  if, and only if, the system call was successful, tell the tool that
84the memory was written:
85
86     if (ARG1 != 0) {
87        POST_MEM_WRITE( ARG1, sizeof(vki_time_t) );
88     }
89
90The POST() function won't be called if the syscall failed, so you
91don't need to worry about checking that in the POST() function.
92(Note: this is sometimes a bug; some syscalls do return results when
93they "fail" - for example, nanosleep returns the amount of unslept
94time if interrupted. TODO: add another per-syscall flag for this
95case.)
96
97Note that we use the type 'vki_time_t'.  This is a copy of the kernel
98type, with 'vki_' prefixed.  Our copies of such types are kept in the
99appropriate vki*.h file(s).  We don't include kernel headers or glibc headers
100directly.
101
102
103Writing your own syscall wrappers (see below for ioctl wrappers)
104~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
105If Valgrind tells you that system call NNN is unimplemented, do the 
106following:
107
1081.  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
1162.  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
1263.  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
1684.  Once happy, send us the patch.  Pretty please.
169
170
171
172
173Writing your own ioctl wrappers
174~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
175
176Is pretty much the same as writing syscall wrappers, except that all
177the action happens within PRE(ioctl) and POST(ioctl).
178
179There's a default case, sometimes it isn't correct and you have to write a
180more specific case to get the right behaviour.
181
182As above, please create a bug report and attach the patch as described
183on http://www.valgrind.org.
184
185

README_PACKAGERS

1
2Greetings, packaging person!  This information is aimed at people
3building binary distributions of Valgrind.
4
5Thanks for taking the time and effort to make a binary distribution of
6Valgrind.  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
94If you find any more hints/tips for packaging, please report
95it as a bugreport. See http://www.valgrind.org for details.
96