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
-new_linker to the stuff given to the linker, else link failures
result on x86. Based on a suggestion by Christoph Erhardt. Fixes
#295427.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12766
WRT the memcheck test: the good news is we get all the complaints
we want. The bad news is:
- the line numbers from within do_cu21 are off
- there are 2 complaints when attempting to convert from
an uninitialised input buffer instead of one. One of them has a
completely bogus line number.
Possibly due to bad debug info? Let's see what happens on machines
with more recent GCCs.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12765
This means, that any guest state and/or memory accesses of the helper (and
complaints about those) only occur if the guard expression is true at runtime.
Definedness of parameters that the helper might have is *always* checked,
as parameters are evaluated regardless of the guard expression.
New functions: expr2vbits_guarded_Load and gen_guarded_load_b.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12762
Valgrind was crashing systematically on Android 4.1.
This crash is caused by AT_IGNORE-ing AT_BASE.
This AT_IGNORE was needed to have breakpoints in shared libs
be handled properly (not very clear what is the problem
in the interaction between Valgrind GDBSERVER, AT_BASE and GDB).
Waiting to better understand all this, as a temporary bypass,
this patch ensures we do not ignore the AT_BASE on android.
The possible consequence is that breakpoints might be inserted
by the Valgrind gdbserver at wrong addresses in shared lib.
(any feedback on that is welcome).
Valgrind was build and then "proved" to work on Android emulator 4.0
and emulator 4.1, by using memcheck on one executable.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12758
Scanning 1GB of random values made of 200_000 malloc-ed block is
(on amd64) changing from (about) 17 seconds to (about) 10 seconds.
On x86, it goes from 153 seconds to 129 seconds.
(this huge difference between x86 and amd64 leak search time
for this random test is because a random value has about one chance
on 4 to be in the addressable memory on x86 and so the dichotomic
search in the list of malloc-ed blocks is called for a lot more
values than on amd64).
Basically, there are 3 optimisations:
1. call MC_(is_within_valid_secondary) only at the beginning of a
secondary map (and not for each Word).
2. call SETJMP only at the beginning of a page (and not for each Word)
3. Validate an aligned word using get_vabits8 rather than get_vabits2.
Each of the above optimisation more or less improves by 2 seconds.
(to go from 17 seconds to 10 seconds).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12756
(spotted by Julian)
Note: there is a second occurence of call to track_post_mem_write in the
same file; but this second occurence is better done with an "if".
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12755
The header file has been extended with the missing syscall numbers for MIPS,
and sys_prlimit64 has been enabled. This will make none/tests/rlimit64_nofile
pass.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12752
Support has been added to the tests for MIPS32 revision 1. Previously, all the
tests had to be compiled for MIPS32r2 platforms.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12751
The leak search verifies if an address scanned is in a fully
unaddressable secondary map (64 Kb).
However, the function checking that wrongly verifies
if the address is in an ignore range.
So, if the scan encounters one or more bytes in an ignore
range, the leak scan will erroneously skip the rest of
the 64Kb chunk.
The solution is to not test for ignore range in the function
MC_(is_within_valid_secondary) :
The fact that the address is in an ignore range is in any case
verified in the call to MC_(is_valid_aligned_word), which
is called for every Word just after.
This bug can cause false positive leaks in case small
ignore ranges are specified.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12734
