valgrind-users

[Valgrind-users] REPE then 0xF

[Dominic M. <dma...@ai...>]

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
> 

Re: [Valgrind-users] REPE then 0xF

[John R. <jr...@Bi...>]

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, jr...@Bi...

Re: [Valgrind-users] REPE then 0xF

[Bastien C. <ba...@ch...>]

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. --