Most of these instructions required adding a new Iop as they could not
be emulated with existing Iops. In some cases, some of the above instrctions
could be emulated using another instruction from the above list.
Most of the instructions add support for 128-bit instructions. There are a
number of helper functions that check a values for zero, infinity, NaN, etc.
for various sizes. The new 128-bit instructions require a new version of these
existing functions for a 128-bit operand. Rather then adding another size
specific version of these functions, the existing size specific functions were
replaced with a single function that takes the size of operand to be operated
on. There are some additional helper functions that are added to support
the size independent version of these functions.
Note this is the last of the 5 patches required to complete the ISA 3.0
support.
Julian Seward [Wed, 3 Aug 2016 11:53:11 +0000 (11:53 +0000)]
arm32 backend stuff needed to support IR artefacts resulting from
guest support of 32-bit V8 crypto instructions:
* add new pseudo-instruction ARMin_VXferQ, to move values between
two D regs and a Q reg, in either direction. Use this to implement
Iop_64HLtoV128 much more efficiently than before, and to implement
Iop_V128HIto64 and Iop_V128to64.
* Generate code for helper calls in which have four or more
(32-bit) word-sized arguments and a V128 return value.
These require passing arguments on the stack.
dis_neon_data_3same: for the case A==12, don't silently produce invalid IR
which then causes the sanity checker to abort the run. Instead synthesise
a SIGILL in the normal way.
If an instruction can't be decoded, print the first 10 bytes at RSP
rather than 8. 8 is not enough to disambiguate the instruction in
some situations, in particular where there is a control immediate byte
at the end of the instruction.
dis_pc_relative, case 0x002: remove a path that cannot be taken. That
stops gcc -Og complaining. It complains because at that relatively
low level of optimisation, its flow analysis is apparently too weak to
see that the removed path cannot be taken and so it complains
(wrongly) about a possibly uninitialised use of |result|. No
functional change.
Carl Love [Mon, 13 Jun 2016 17:27:03 +0000 (17:27 +0000)]
Fix mtfsfi usage of W bit. (isa2.05,ppc64)
Fix mtfsfi usage of W bit.
The Wbit field was added in ISA 2.05, allowing updates to the 'other'
half of the 64-bit FPSCR field.
Logic and Support for that bit is in place, but a 'reserved field
must contain zeros' check was not updated, preventing the desired
path from being taken.
Bugzilla 362894
Signed-off-by: Will Schmidt <will_schmidt@vnet.ibm.com>
Patch reviewed and verified by: Carl Love <cel@ibm.com>
Petar Jovanovic [Sat, 21 May 2016 00:05:34 +0000 (00:05 +0000)]
mips: allow building code with -mfpxx
Some recent GCC-based toolchains and Debian as a distribution enable the
flag -mpfxx by default. -mfpxx implies -mno-odd-spreg, so use of odd-
numbered single-precision floating-point registers has to be avoided in
Valgrind inline assembly in that case.
Carl Love [Tue, 26 Apr 2016 19:52:56 +0000 (19:52 +0000)]
Power PC Fix V bit error in 128-bit BCD add and subtract instructions
The original code was using the bcdadd / bcdsub instruction on the operand
shadow bits to calculate the shadow bits for the result. This introduced
non-zero bits shadow bits in the result. The shadow bits for these
instructions should be set to all valid or all invalid. If one of the
argument shadow bits was one, then all of the shadow bits of the result should
be one. Otherwise the result shadow bits should be zero.
This patch fixes the above bug in memcheck/mc_translate.c
Fixing the above bug broke the v-bit test. The issue is the v-bit tester
assumes the shadow bits for the operands of a given Iop can be set to one
for testing purposes. The implementation of the bcdadd and bcdsub was passing
a constant value for the variable ps. The ps value is an argument to the
instruction that specifies how to set the sign code of the result. The
implementation of the instructions was changed to issue the instruction with
ps=0. Then the result of the instruction is updated in the VEX code if ps=1.
This changed also results in cleaning up the vbit test code.
This patch also fixes the issues with the v-bit test program.
Carl Love [Tue, 29 Mar 2016 21:27:20 +0000 (21:27 +0000)]
Power PC Add support for ISA 3.0, part 1
The Floating-point condition code bits FPCC is bits[15:12] of the FPSCR.
The instructions fcmpu, fcmpo, dcmpu, dcmpq, dtstdc, dtstdcq, xscmpodq
and xscmpudq set the FPCC bits in addition to the BE field of the CC
register. This support is needed by the ISA 3.0 instructions to be added.
Carl Love [Tue, 16 Feb 2016 21:20:24 +0000 (21:20 +0000)]
128bit modulo and carry instruction fix
This patch fixes an issue with caculating the carry to the next 32-bit
chunk for the 128-bit add and subract instructions: vaddcuq, vadduqm,
vsubcuq, vsubuqm, vaddecuq, vaddeuqm, vsubecuq, vsubeuqm
Carl Love [Tue, 3 Nov 2015 17:44:55 +0000 (17:44 +0000)]
Add ISA 2.07 vbit test support
The ISA 2.07 support adds new Iops as well as support for some existing
Iops. None of these Iops have been enabled in the vbit tester. This commit
adds the needed support to the files VEX/priv/ir_inject and VEX/pub/libvex.h.
These changes add support for additional immediate operands.
There are additional changes to the memcheck files to complete the ISA 2.07
support.
Florian Krohm [Fri, 16 Oct 2015 17:26:22 +0000 (17:26 +0000)]
Give typeOfPrimop external linkage. This allows us to simplify
memcheck/tests/vbit-test which used to have local copies of certain
functions from ir_defs.c
Mark Wielaard [Thu, 1 Oct 2015 12:31:19 +0000 (12:31 +0000)]
Don't advertise RDRAND in cpuid for Core-i7-4910-like avx2 machine.
Bug#353370. In amd64g_dirtyhelper_CPUID_avx2 we set the RDRAND bit
but we don't implement support for RDRAND. Turn the bit off so programs
don't try to use RDRAND when running under valgrind.
Carl Love [Mon, 21 Sep 2015 21:46:46 +0000 (21:46 +0000)]
Fix, Add support for the Power PC Program Priority Register
Commit r3189 had a typo in it. In function LibVEX_GuestPPC64_initialise()
the value of vex_state->guest_PSPB is initialized to 0x0. The intention was
for it to be initialized to 0x100. This commit fixes the typo.
The original commit message:
Added the Program Priority Register (PPR), support to read and write it
via the mfspr and mtspr instructions as well as the special OR instruction
No Op instructions. The setting of the PPR is dependent on the value in
the Problem State Priority Boost register. Basic support for this register
was added. Not all of the PSPB register functionality was added.
Carl Love [Wed, 16 Sep 2015 22:26:59 +0000 (22:26 +0000)]
Add support for the Power PC Program Priority Register
Added the Program Priority Register (PPR), support to read and write it
via the mfspr and mtspr instructions as well as the special OR instruction
No Op instructions. The setting of the PPR is dependent on the value in
the Problem State Priority Boost register. Basic support for this register
was added. Not all of the PSPB register functionality was added.
s390: Add support for fixbr(a) instructions.
New IROp Iop_RoundF128toInt.
Patch by Andreas Arnez <arnez@linux.vnet.ibm.com>.
Part of fixing BZ #350290.
Petar Jovanovic [Mon, 13 Jul 2015 00:04:28 +0000 (00:04 +0000)]
mips: emit addiu instead of addi
Remove wrong emission of addi when addiu is correct, sufficient and needed.
Attention to this part of the code has been brought by BZ #338924. This
patch fixes the reported issue as well.
Add some functions for misaligned load/store support, and use them
in the x86 and amd64 chainer/unchainer. This makes it possible to
run at least some programs when built with gcc 5.1, with ubsan misaligned
checking enabled.
Petar Jovanovic [Wed, 24 Jun 2015 18:47:39 +0000 (18:47 +0000)]
mips64: do not use 64-bit loads for lwl/lwr instructions
As reported in BZ #346562, lwl/lwr were implemented incorrectly using
64-bit loads. This has led to incorrect "invalid read of size 8"
warnings. This patch fixes it, and it does some formatting to make the
code more readable.
Original version of the patch proposed by Crestez Dan Leonard.
A SSE2 only CPU was reported to the guest as a SSE3 CPU.
The guest code might then select functions calling invalid
instructions.
E.G. giving:
vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x3A 0xF
==13094== valgrind: Unrecognised instruction at address 0x496d4d3.
==13094== at 0x496D4D3: __mempcpy_ssse3 (memcpy-ssse3.S:771)
==13094== by 0x125E0B: ??? (in /bin/dash)
as the host hw cap is not SSE3 enabled, while the guest believes
SSE3 can be used.
So, change CPUID so as to report an SSE3 if the hw is SSE3,
and otherwise SSE1 or lower.
Carl Love [Fri, 5 Jun 2015 18:52:57 +0000 (18:52 +0000)]
Opps, missed a change in the previous patch. Forgot to remove the format
specifier.
The dcbt and dcbtst instructions provide a non-zero hint that describes
a block or data stream to which a program may perform a Store acces,
or indicates the expected use. The field bits[25:21] (bits 6:10 in
the IBM numbering) in the instruction provide the hint.
Valgrind checks that these bits are non-zero. Unfortunately, the test was
being applied to other instructions such as the dcbf instruction causing
it to fail when the field was equal to zero. This patch removes the check
that was being incorrectly applied to all of the instructions.
Carl Love [Fri, 5 Jun 2015 17:58:23 +0000 (17:58 +0000)]
The dcbt and dcbtst instructions provide a non-zero hint that describes
a block or data stream to which a program may perform a Store acces,
or indicates the expected use. The field bits[25:21] (bits 6:10 in
the IBM numbering) in the instruction provide the hint.
Valgrind checks that these bits are non-zero. Unfortunately, the test was
being applied to other instructions such as the dcbf instruction causing
it to fail when the field was equal to zero. This patch removes the check
that was being incorrectly applied to all of the instructions.
Carl Love [Wed, 29 Apr 2015 20:37:29 +0000 (20:37 +0000)]
Improve the error messages for the PPC platform to be more clear when Valgrind detects that
the underlying hardware doesn't have the needed capability. A number of the checks for DFP
support were going to "decode_failure" instead of "decode_noDFP". These issues are also fixed.
Remove VexGuestTILEGXStateAlignment as the guest state size of any architecture
must satisfy the LibVEX_GUEST_STATE_ALIGN requirement. So use that instead.
Carl Love [Wed, 22 Apr 2015 16:15:41 +0000 (16:15 +0000)]
Add support for the TEXASRU register. This register contains information on
transactional memory instruction summary information. This register contains
the upper 32-bits of the transaction information. Note, the valgrind
implementation of transactional memory instructions is limited. Currently, the
contents of the TEXASRU register will always return 0. The lower 64-bits of
the trasnaction information in the TEXASR register will contain the failure
information as setup by Valgrind.
This commit contains the changes needed to support the TEXASRU register on
PPC64.
This support requires changing the value of MAX_REG_WRITE_SIZE in
memcheck/mc_main.c from 1696 to 1712. The change is made in the corresponding
valgrind commit.
Carl Love [Fri, 17 Apr 2015 23:42:40 +0000 (23:42 +0000)]
Add support for the lbarx, lharx, stbcx and sthcs instructions.
The instructions are part of the ISA 2.06 but were not implemented
in all versions of hardware. The four instructions are all supported
in ISA 2.07. The instructions were put under the ISA 2.07 category
of supported instructions in this patch.
projects / thirdparty / valgrind.git / log
