Change IR generation for SRST, CLST, and CLCLE to not generate cc=3.
Two reasons:
(1) Consistency in implementation (we don't generate cc=3 for "translate",
"convert to unicode" and possibly other insns)
(2) There is nothing to be gained. A program that does not handle cc=3
correctly (by looping back to the insn that generated it) may exhibit
unpredictable behaviours. And there is no way for us to match that (as
we cannot know when hardware decides to interrupt the insn). So why
add complexity for that.
Better document the limitation of gdbsrv for registers and flags values
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.
Have perf/vg_perf handling EXTRA_REGTEST_OPTS
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).
Back out special handling for opcode 00 (VEX r2189).
This was added based on the following analysis at the time:
(1) during decoding a sequence of insns we run into a 00 opcode (as that
opcode is sometimes used on purpose to force an abort)
(2) #1 only happens when chasing through unconditional gotos
(3) the path that was decoded in #1 would not be executed because an earlier
side exit in the super block was taken
But chasing through an unconditional branch should not reach an insn that is
not reached at execution time, because
(a) conditional gotos are supposed to terminate a superblock
(b) side exits that appear in the IR of complex insns will transfer control
to the very same address (for insns that have implicit loops) and/or to
the address that immediately follows the current insn (fall through)
Therefore, the special handling of opcode 00 was just fighting the
symptom but not the cause.
Most likely a super block was not correctly terminated.
Petar Jovanovic [Mon, 23 Jul 2012 00:11:10 +0000 (00:11 +0000)]
Avoid checking for bitset initialization if futex_wait_bitset is meant to fail.
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.
Add 'aesdec' to the set of insns checked for assembler level SSE4.2
support (Rich Coe) and tidy up a couple of other bits of assembly by
giving them trashed-register lists.
Change logic in computed gotos to use if_condition_goto_computed
instead of if_not_condition_goto_computed. Hide the implementation
detail of inverting the condition in if_condition_goto_computed and
fix the call sites. This is clearer as it better matches the semantic
description in the POP.
ppc64-linux _start: don't assume ._start_in_C_linux -- the function
descriptor for _start_in_C_linux -- actually exists. Instead call the
entry point directly.
If the compiler being used to build is clang, remember to add
-new_linker to the stuff given to the linker, else link failures
result on x86. Based on a suggestion by Christoph Erhardt. Fixes
#295427.
Add testcases for CU21. Update opcode table.
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.
Observe guards on dirty helpers in memcheck.
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.
Fix 303624 segmentation fault on Android 4.1 (e.g. on android emulator or Galaxy Nexus OMAP)
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.
patch that improves the speed of the leak search by up to 40% (on amd64)
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).
Small cleanup: use VG_TRACK (when possible) to call tool tracking functions
(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".
Petar Jovanovic [Mon, 16 Jul 2012 14:35:26 +0000 (14:35 +0000)]
Add some missing syscall numbers for MIPS.
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.
Handle UD2 a bit better. This change causes Vex to decode UD2 like
any other instruction -- so it doesn't complain -- but Valgrind still
complains when synthesising the SIGILL for the guest. Marginally less
confusing than it was before.
Increase max allowed pre-allocation (vreg-ised) block size from 10000
to 15000. In very extreme circumstances the JIT pipeline can create
huge blocks. Fixes #303250, at least for the time being.
Fix bug in leak search when an ignore range is specified
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.
295590 Helgrind: Assertion 'cvi->nWaiters > 0' failed when cond var being waited upon destroyed
* when cond var is destroyed, in the PRE, report an error if nwaiters > 0.
* when cond_wait succeeds, get the cond var but do not create one in helgrind
(it must exist if cond_wait was done).
Report an error if cond not found (assuming this is caused by a destroy
done while the thread was cond_wait-ing).
* added a test
fix 303127 Power test suite fixes for frsqrte, vrefp, and vrsqrtefp instructions
The frsqrte and vrefp instructions produce an approximate result.
According to the ISA document for the POWER processor, the result will
vary in its precision for different processor implementations. This patch
fixes the masks to be applied to the results to remove the variability
in the results. The expected output files are also updated to reflect the
change in the result given the new masking of the result.
Make the IR sanity checker complain about dirty helpers that return
a value and are executed under a condition. That case is not handled
properly and will cause asserts down the road. As pointed out by Julian.
Improve behaviour of mempool redzone checking if user does not follow the manual (297911)
User is supposed to mark the superblock(s) of a mempool as noaccess.
As Valgrind objective is to find bugs for users which are doing bugs, let's even
find (some) bugs if the user has a bug in the bug detection code.
projects / thirdparty / valgrind.git / log
