valgrind does not support ivybridge rdrand instruction

[Colin Ian King]

Valgrind does not support Ivybridge rdrand instructions in Oneiric but gcc does support it.

#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>

static inline uint16_t rdrand16(void)
{
        uint16_t val;
        int error;

        do {
                asm("rdrand %%ax;\n\
                mov $1,%%edx;\n\
                cmovae %%ax,%%dx;\n\
                mov %%edx,%1;\n\
                mov %%ax, %0;":"=r"(val),"=r"(error)::"%ax","%dx");
        } while (error == 0);

        return val;

}

main(int argc, char *argv[])
{
        printf("%d\n", (int)rdrand16());
}

$ gcc -O5 rdrand.c
$ valgrind --version
valgrind-3.6.1
$ valgrind ./a.out
==5007== Memcheck, a memory error detector
==5007== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==5007== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==5007== Command: ./a.out
==5007==
vex amd64->IR: unhandled instruction bytes: 0x66 0xF 0xC7 0xF0 0xBA 0x1
==5007== valgrind: Unrecognised instruction at address 0x4004fb.
==5007== Your program just tried to execute an instruction that Valgrind
==5007== did not recognise. There are two possible reasons for this.
==5007== 1. Your program has a bug and erroneously jumped to a non-code
==5007== location. If you are running Memcheck and you just saw a
==5007== warning about a bad jump, it's probably your program's fault.
==5007== 2. The instruction is legitimate but Valgrind doesn't handle it,
==5007== i.e. it's Valgrind's fault. If you think this is the case or
==5007== you are not sure, please let us know and we'll try to fix it.
==5007== Either way, Valgrind will now raise a SIGILL signal which will
==5007== probably kill your program.
==5007==
==5007== Process terminating with default action of signal 4 (SIGILL)
==5007== Illegal opcode at address 0x4004FB
==5007== at 0x4004FB: rdrand16 (in /home/ubuntu/a.out)
==5007== by 0x400538: main (in /home/ubuntu/a.out)
==5007==
==5007== HEAP SUMMARY:
==5007== in use at exit: 0 bytes in 0 blocks
==5007== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==5007==
==5007== All heap blocks were freed -- no leaks are possible
==5007==
==5007== For counts of detected and suppressed errors, rerun with: -v
==5007== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
Illegal instruction (core dumped)

[Alessandro Ghedini (ghedo)]

Here is a shorter test case:

% cat rdrand.c
int main(void) {
 asm(".byte 0x66, 0xF, 0xC7, 0xF0, 0xBA, 0x1");

 return 0;
}

Disassembled by gdb as:

   0x00000000004004a0 <+0>: mov eax,0x0
   0x00000000004004a5 <+5>: mov DWORD PTR [rsp-0x4],0x0
   0x00000000004004ad <+13>: rdrand ax
   0x00000000004004b1 <+17>: mov edx,0x9090c301

[Pjfloyd (pjfloyd)]

This was fixed upstream ages ago

commit 472b067e39a11a47ae3fa7cd7d3142558f78969d
Author: Julian Seward <email address hidden>
Date: Sun Mar 17 21:41:42 2019 +0100

    amd64: Implement RDRAND, VCVTPH2PS and VCVTPS2PH.

    Bug 398870 - Please add support for instruction vcvtps2ph
    Bug 353370 - RDRAND amd64->IR: unhandled instruction bytes: 0x48 0xF 0xC7 0xF0

    This commit implements:

    * amd64 RDRAND instruction, on hosts that have it.

    * amd64 VCVTPH2PS and VCVTPS2PH, on hosts that have it.

      The presence/absence of these on the host is now reflected in the CPUID
      results returned to the guest. So code that tests for these features in
      CPUID and acts accordingly should "just work".

    * New test cases, none/tests/amd64/rdrand and none/tests/amd64/f16c. These
      are built if the host's assembler can handle them, in the usual way.