put the to-be-modified insns in an mmap'd page
- Clarify init_function a bit (does not change what it does)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5567
distinction between primary and secondary build targets, and (2) make
it independent of the default behaviour of gcc (iow, what gcc does
when you specify neither -m32 nor -m64).
As a result, an out-of-the-box build on ppc64-linux now builds a
system which is basically for 64-bit PowerPC, but also has the ability
to run 32-bit ppc-linux binaries (exactly the same arrangement as you
get when building on amd64-linux).
There are various twists and turns. multiple-architectures.txt is
updated all the gory details.
This will break amd64 builds until such time as
<tool>/tests/{amd64,x86}/Makefile.am are fixed up (shortly).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5493
- More cleanup
- Fixed rlwimi test - init r_dst to zero.
- Fixed load/store tests - print change in updated base reg, not actual value.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5486
- needed some hackery to get around VEX's loss of accuracy.
------------------------------
Added test for fsqrt (fp square root)
Enabled stfs(u)(x) (fp single-precision stores)
- VEX implementation not great: ends up rounding twice, losing
accuracy, but is good enough for this test's small fp argument array.
Changed fp arg setup
- no denormals (for VEX inaccuracy)
All fp tests
- don't print CR, XER flags, as VEX doesn't set them.
3 arg fp arith tests (fp 'multiply and add' etc)
- no 'special' fp vals (for VEX inaccuracy)
- zap lo byte (for VEX inaccuracy)
fctiw, fctiwz (fp convert to int)
- zap high 32bits of result (is undefined)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5344
natively):
- register_vfarg: stuff bits directly into vector, don't go via float
as that screws up NaNs somehow on MPC7447
- test_av_int_ld_two_regs: lve{b,h,w}x: mask off bits of the result
register which are undefined after the load
- test_av_int_st_three_regs: fix result vector size
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5208
- Non-Java mode is the system default, but was causing some accuracy problems by rounding off intermediate denormalised results to zero.
We now have some small errors (lowest bit only) due to using greater accuracy than the system default, but is better overall.
Also expanded dispatcher check of FPSCR to include all contol bits
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5196
Plenty still to do, but simple programs like ls seem to run ok
Thanks, Paul, for having your ppc port of valgrind 2.4 to work from!
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3969
