|
From: Carl E. L. <ce...@us...> - 2015-09-14 17:37:43
|
On Mon, 2015-09-14 at 11:56 -0500, Peter Bergner wrote:
> On Mon, 2015-09-14 at 09:03 -0700, Carl E. Love wrote:
> On Sat, 2015-09-12 at 20:50 +0200, Florian Krohm wrote:
> >> while looking at the vbit-test failure on ppc32 I noticed that in
> >> guest_ppc_toIR.c all dis_dfp_XYZZY functions are guarded by
> >> if (!allow_DFP) goto decode_noDFP
> >> except the two below. An oversight ?
> >
> > Yes, this does appear to be an oversight as these instructions use an
> > Iop that was created specifically for these instructions. PPC32 does
> > not have DFP support so trying to test the Iop on ppc32 would be an
> > issue.
>
> If by PPC32 you mean 32-bit hardware, then yes I know of no 32-bit
> hardware that supports DFP. OTOH, if by PPC32 you mean 32-bit
> applications, then PPC32 DOES support DFP is that 32-bit application
> is run on a POWER6 or later server hardware. To really determine
> if DFP is supported or not, you really should look at whether the
> "dfp" flag is set in the AT_HWCAP. The same is true of altivec,
> vsx, etc.
The check in Valgrind for allow_DFP that Florian mentioned in his patch
case 0x322: // POWER 7 inst, dcffix - DFP convert from fixed
if (!allow_VX)
goto decode_failure;
+ if (!allow_DFP) goto decode_noDFP;
if (dis_dfp_fmt_conv( theInstr ))
goto decode_success;
is based on checking the underlying hardware caps for
VEX_HWCAPS_PPC64_DFP
Note, Valgrind only checks for this if the machine is either ppc64 big
endian or ppc64 little endian.
So, in this case the two instructions that he noted need to be protected
with the statement "if (!allow_DFP) goto decode_noDFP;" to ensure the
underlying hardware does not try to issue the DFP instruction.
Carl Love
|