|
From: Dominic M. <dma...@ai...> - 2003-05-02 17:13:29
|
Was anyone else able to reproduce the REPE then 0xF problem using my test
program? Just curious...
- Dominic
> Message: 10
> Date: Mon, 28 Apr 2003 19:21:08 -0700 (PDT)
> From: Dominic Mazzoni <dma...@ai...>
> To: val...@li...
> Subject: Re: [Valgrind-users] Need test case for: REPE then 0xF: Unhandled
> REPE case
>
> Here's a very short test program that produces this error for me. I'm
> using a Pentium 3, though, not a Pentium 4. The problem only happens if I
> use the -march=pentium3 option with gcc 3.x.
>
> Test program:
>
> #include <stdio.h>
> #include <stdlib.h>
>
> int main(int argc, char **argv)
> {
> float f = rand() / (float)RAND_MAX;
> printf("f=%f\n", f);
>
> return 0;
> }
>
> Compilation line:
>
> gcc -march=pentium3 foo.c
>
> > gcc -v
> Thread model: posix
> gcc version 3.2
>
> > valgrind --version
> valgrind-1.9.4
>
> I hope this helps!
>
> - Dominic
>
> ---------------------------------------------------------------
>
> From: Julian Seward <js...@ac...>
> To: val...@li...
> Date: Sun, 27 Apr 2003 00:13:43 +0100
> Subject: [Valgrind-users] Need test case for: REPE then 0xF: Unhandled
> REPE
> case
>
>
> Hello. I'm trying to put together bug fixes for 1.9.6.
>
> Several people reported this panic:
>
> REPE then 0xF
>
> valgrind: the `impossible' happened:
> Unhandled REPE case
>
> I'd like to fix it, since it seems to afflict quite a number
> of people. However, reading my Intel P4 documentation I can't
> figure out what instruction this is.
>
> So: does anyone have a smallish test case I can use to reproduce
> this with? Or (not so good, but it would be a help) can anyone
> tell me what the byte after the 0xF is? You can find out
> by changing vg_to_ucode.c:4321 from
>
> VG_(printf)("REPE then 0x%x\n", (UInt)abyte);
>
> to
>
> VG_(printf)("REPE then 0x%x 0x%x\n", (UInt)abyte,
> (UInt)getUChar(eip));
>
> I prefer a test case tho, so I can test any fix I make.
>
> Thanks,
>
> J
>
>
>
>
>
>
> --__--__--
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>
> End of Valgrind-users Digest
>
|
Dominic Mazzoni wrote: > Was anyone else able to reproduce the REPE then 0xF problem using my test > program? Just curious... From IA-32 Intel Architecture Software Developer's Manual, Volume 2: Instruction Set Reference (24547107.pdf on developer.intel.com; perhaps 2454108.pdf by now): CMPSS -- Compare Scalar Single-Precision Floating-Point Values F3 0F C2 /r ib CMPSS xmm1, xmm2/m32, imm8 CMPSD -- Compare Scalar Double-Precision Floating-Point Values F2 0F C2 /r ib CMPSD xmm1, xmm3/m32, imm8 MOVQ2DQ -- Move Quadword from MMX to XMM Register F3 0F D6 MOVQ2DQ xmm, mm MOVDQ2Q -- Move Quadword from XMM to MMX Register F2 0F D6 MOVDQ2Q mm, xmm CVTDq2PD -- Convert Packed Doubleword Integers to Packed Double-Precision Floating- Point Values F3 0F E6 CVTDQ2PD xmm1, xmm2/m64 CVTD2DQ -- Convert Packed Double-Precision Floating-Point Values to Packed Doubleword Integers F2 0F E6 CVTPD2DQ xmm1, xmm2/m128 So seeing "F3 0F ..." is not surprising: it is specified behavior, and very reasonable for a compiler to generate CMPSS. Furthermore, past generations of hardware always accepted prefixes in any order. So in theory "0F F3 ..." would be equivalent. Perhaps there is a move to require that 0F be the last prefix (it might simplify decoding), but that would break backwards compatibility in many cases. 0F could be required as last only for new instructions, of which CMPSS certainly is one. But then the checking to require 0F last, only in these 6 cases, might cost more than just allowing arbitrary order all the time. [Basically, the opcode space is over-full.] -- John Reiser, jreiser@BitWagon.com |
|
From: Bastien C. <ba...@ch...> - 2003-05-02 18:12:48
|
On Friday 02 May 2003 19:13, Dominic Mazzoni wrote:
> Was anyone else able to reproduce the REPE then 0xF problem using my test
> program? Just curious...
Yes. Even if I could not run it natively (Athlon), valgrind dutifully choked
when it encountered the 0xf problem :-)
Just thinking of it: valgrind should therefore also qualify as processor
emulator, shouldn't it? Like letting run code specifically compiled for the
PI-IV on Athlons and vice versa.
B.
--
-- The universe has its own cure for stupidity. --
-- Unfortunately, it doesn't always apply it. --
|