rev 12001 has introduced a regression in VG_(env_remove_valgrind_env_stuff):
to avoid modifying a possibly read-only env string, the string is duplicated,
and the copy is modified. However, mash_env_column modifies the string
"in-place". The modified string was not put back in the env (and could not,
because the src string is only partially copied).
This means that the valgrind preload strings were not cleaned up and
when a 32 bit executable execs a 64 bits (or vice versa: 64 bit execs 32 bits),
LD_PRELOAD contains both the 32 bits and 64 bits versions of Valgrind
vgpreload.... => ld.so then gives an error msg, as it can't preload either
the 32 or the 64 bits version.
The patch fixes this by duplicating the whole env string, and passing
to mash_colon_env a pointer to the correct offset in the whole env string.
The duplicated string is replacing the original entry in envp.
This patch adds two regression tests : none/tests/allexec32 and
none/tests/allexec64. On a bi-arch valgrind, these will be 32bits and 64 bits
executables, exec-ing each other. On a single arch, one will be a symlink
to the other (to avoid different .exp files, and still test exec).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12287
is set. This ensures a correct help msg is given when
the valgrind installation is moved, and VALGRIND_LIB is
then set to the new valgrind lib location.
Note it does not improve the help msg when valgrind
is run "in place" (e.g. when using vg-in-place).
(Patch from Paul Pluzhnikov).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12278
- mention s390x/linux in README
- formatting tweak in README.s390 so things don't look ugly in html
- add README.s390 and README.android to distribution documents
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12277
in the valgrind-www repository. These files are actually generated
from AUTHORS and NEWS, respectively.
Therefore, change AUTHORS and NEWS to reflect yesterday's change.
Things are now in synch again.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12276
specified, the handler returns to the previous context rather than to
whatever value happens to be parked in the link register (duh).
Previous behaviour made complete nonsense of signal returning on
Android.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12273
So, replace the code which counts the nr of bits in the level0
bitmap by just returning the nr of elements in use.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12272
To detect calls and returns, Callgrind's heuristic
starts with using the jumpkind got from VEX for
a control flow change instruction. However, for
side exits, it always assumed a (conditional) jump,
which holds true for x86, but e.g. not for ARM.
This fixes Callgrind to use the jumpkind found
by VEX for all exits, which should help making
Callgrind work for ARM. It also moves the check
whether a boring jump is actually a fall-through
to instrumentation time. This changes (fixes) the
result for indirect jumps to the next instruction,
which should not be classified as fall-through
(anyway, this case is probably very rare).
This patch introduces an own enum for jump kinds
in Callgrind. This is less confusing than misusing
the VEX jump kind type, as Callgrinds wants
to distinguish BB fall-throughs from real jumps
(which both are Ijk_Boring in VEX).
Also, setup_bbcc now stores separately whether the
jump kind is conditional or not.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12269
This is the last part of moving from command file polling
to the vgdb ptrace method for interactive control of Callgrind.
VG 3.7.x ported callgrind_control to vgdb (in r11867), but
still did command file polling to support existing KCachegrind
releases. KCachegrind from upcoming KDE SC 4.8 will use
callgrind_control instead of manually writing command files.
The main benefit from this is, apart from getting rid of
continous file polling activity in Callgrind, that blocked
processes can now respond to callgrind_control.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12268
fields. This makes the --ct-verbose=1 output make a lot more sense
for Thumb code. Should have no effect on any other platform.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12260
