CmpNE32(1Sto32(bit),0) == bit
and ditto in 64-bits, and do not generate any code for it. This helps
some massive expressions made by memcheck on x86 FP code.
git-svn-id: svn://svn.valgrind.org/vex/trunk@546
boundaries, so as to make the intercept mechanism work properly again.
Unfortunately also contains a huge number of tab-to-space whitespace
changes in guest-x86/toIR.c.
git-svn-id: svn://svn.valgrind.org/vex/trunk@537
detailed comment in priv/guest-x86/gdefs.h. In short we move to a
4-word thunk so as to be able to present Memcheck with the data
dependencies we want, and at the same time allow iropt to easily
optimise away most of the helper calls that evaluate the thunk.
Hopefully this is the last change.
Comment in priv/guest-x86/gdefs.h also explains properly the
relationship between the thunk arrangements and how we expect Memcheck
to behave with respect to definedness of flags.
git-svn-id: svn://svn.valgrind.org/vex/trunk@525
it. Instead, observe that all of the residual errors are from
stpcpy/strnlen in glibc. Then observe that the redirect mechanism
seems to fail to redirect these to our "safe" equivalents. Then,
finally realise that the redirect mechanism is defeated by vex's
cross-BB-chasing and specifically by chasing across function call
boundaries.
So, the good news is that giving --vex-guest-chase-thresh=0 makes all
these errors go away. This should be straightforward to fix properly.
git-svn-id: svn://svn.valgrind.org/vex/trunk@518
unsuccessful):
* in clean helper calls, take notice of exclusion-mask (mcx_mask)
specifying which args to ignore. Seems to have no effect.
* Add Paul-Mackerras-style expensive-add. Seems to have no effect.
* When doing a shadow PUT, do not complain if uninitialised data
is written to guest state areas which are marked in the layout info
as 'always defined'. This seems to help reduce the false positive
rate, because (in guest x86) the CC_AUX field of the flags thunk
is sometimes given an undefined value (old C flag) when setting
the thunk after inc/dec. Since we assume that no compiler would
examine the C flag after inc/dec unless it knew the C flag before it
was defined (inc/dec do not change C), this is assumed to be safe.
git-svn-id: svn://svn.valgrind.org/vex/trunk@506
hints to Memcheck about which arguments in a helper call should be
ignored when it comes to computing lazy approximations of definedness
through that function. Not sure if this mechanism needs to remain,
but for the time being ...
git-svn-id: svn://svn.valgrind.org/vex/trunk@504
tons of now-irrelevant baseblock fields and offsets. The layout
defined in coregrind/x86/state.c is now more or less (completely?)
target-independent: vex-defined guest state, vex-defined shadow guest
state, and vex-specified spill area.
git-svn-id: svn://svn.valgrind.org/vex/trunk@503
