Darwin from returning address zero (however insane that is). r12466
appears to cause other applications to break (TextEdit, for one).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12813
The CALL_FN_xx macros in valgrind.h perform function calls by
signalling to valgrind using the client request system. Because
they are making function calls which are invisible to the compiler
they need to make sure that any stack alignment constraints
imposed by the ABI are enforced when making the call.
This commit enforces 16 byte alignment for x86, amd64, ppc32 and
ppc64 platforms, and 8 byte alignment for arm platforms.
It does not touch s390x where the ABI requires 8 byte alignment to
be maintained at all times, not just when making a function call.
It also does not touch mips32 as I'm not currently aware what if
any alignment constraints exist there.
Fixes BZ#304054 and observed alignment faults on amd64 when running
the regtests using a valgrind compiled with gcc 4.7 releases.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12811
If a segment is mapped with permission rwx, then map->rx
and map->rw will be true.
But due to the if (map->rx) {
...
} else if (map->rw) {
...
the (map->rw) part will not be executed.
If this mapping is the one which "gives" the nonempty rw map,
then this mapping will not be seen, and the following
vg_assert(has_nonempty_rw);
will fail.
This assert can be reproduced by doing
setarch i686 -X
./vg-in-place --tool=none none/tests/map_unmap
Note: the setarch i686 -X above has as effect to make all read
mapping also executable. So, a rw mapping becomes rwx and then
triggers the above asserts.
The setarch i686 -X also introduces a discrepancy between
the kernel mappings (rwx) and the valgrind aspacemgr view
(which believes it is a rw mapping).
This discrepancy causes a crash if giving --sanity-level=3.
A possible fix is to have valgrind calling the personality system call
and detecting if the READ_IMPLIES_EXEC bit (the -X arg to setarch)
was set, and then modify aspacemgr so that all read mapped segments
are automatically mapped x also.
This commit is the minimal fix allowing to run executables
launched with this READ_IMPLIES_EXEC.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12810
* Option --vex-iropt-precise-memory-exns has been removed.
It is replaced by --vex-iropt-register-updates which accepts
3 values : 'unwindregs-at-mem-access' (replacing
--vex-iropt-precise-memory-exns=no), 'allregs-at-mem-access'
(replacing --vex-iropt-precise-memory-exns=yes)
and a new value 'allregs-at-each-insn'.
'allregs-at-each-insn' allows the Valgrind gdbserver to always
show up to date values to GDB.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12809
* For tools replacing the malloc library (e.g. Memcheck, Helgrind, ...),
the option --redzone-size=<number> allows to control the padding
blocks (redzones) added before and after each client allocated block.
Smaller redzones decrease the memory needed by Valgrind. Bigger
redzones increase the chance to detect blocks overrun or underrun.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12807
(NB: I am wondering if these entries should be put in NEWS at all.
Is NEWS targetted at end users only ?
Or at "tool developper users also' ?)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12796
MIPS has different signal values, so it has to have its own expected output for
the tests that deal with signal values.
This fixes (false) failure in memcheck/tests/sigkill.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12794
MIPS has different signal values, so it has to have its own expected output for
the tests that deal with signal values.
This fixes (false) failure in none/tests/async-sigs.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12791
Idea is from Julian, possible bugs are mine.
If the fun or obj is a simple string and not a patter (so no *, no ?),
use a simple string comparison rather than a call to a wildcard matching.
On a leak search with a lot of reachable loss records and a lot of suppr,
it improves the speed of the leak search by 10 to 15%.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12789
- advance the guest_IA to the next insn after raising the signal
- adjusting the address in a complaint to point to the failing insn
(after guest_IA has been advanced)
Update testcases .exp files.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12787
During investigations of 303963, Josef found that flags are not always
up to date and that --vex-guest-max-insns=1 ensures flags values
are (more?) correct.
=> enhance the paragraph in the gdbserver limitations to reference
this option and give an idea of the performance impact of the other
options helping to increase the precision of registers and flags.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12778
Similarly to tests/vg_regtest, allow to run all perf tests with extra options.
(note: it was preferred to use the same env var name).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12777
This is the companion patch to VEX r2444 which backs out the special
handling for the 00 opcode.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12776
Glibc deliberately passes random value for the sixth parameter when calling
FUTEX_WAIT_BITSET | FUTEX_CLOCK_REALTIME. This is a regular case of using the
Futex API, so V should not complain that "Syscall param futex(val3) contains
uninitialised byte(s)", if the futex does not have a specified value initially.
For more info, see function pthread_initialize_minimal_internal at:
glibc/nptl/nptl-init.c.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12773
support (Rich Coe) and tidy up a couple of other bits of assembly by
giving them trashed-register lists.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12772
#define N_FRAMES 8
(defined in libhb_core.c:3888)
implies that 'other thread' stack traces are limited to 8,
even with a bigger --num-callers.
=> document this in the manual to avoid that a user believes this is a
bug in the stack trace logic of Valgrind.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12767
