Re: [Valgrind-users] Incorrect results from inline assembly when running under Valgrind

[Jeffrey W. <nol...@gm...>]

Thanks John.

> A quick search of the web for "valgrind CPUID" will fill in the details.
For https://bugs.kde.org/show_bug.cgi?id=155528, does Valgrind want
the output for an i5 so it can fake an i5? I use Ivy Bridge i5's
specifically for AES-NI and RDRAND.

Perhpas a --cpu=XXX switch would be helpful for switching between
cpu's. (Forgive me if its non-trivial to do. I know nothing about
Valgrind architecture or operation. I just know a bit about using it
to hunt leaks).

Jeff

On Mon, Feb 10, 2014 at 10:43 PM, John Reiser <jr...@bi...> wrote:
> On 02/10/2014 03:35 PM, Jeffrey Walton wrote:
>> I've got some code that determines CPU capabilities for x86
>> processors. I'm interested in RDRAND and AESNI, and I use three
>> functions to determine the capabilities: HasIntel(), HasAESNI() and
>> HasRDRAND().
>>
>> Debug configurations compiled with GCC and Clang work fine. Release
>> configuration compiled with GCC and Clang work fine.
>>
>> However, I get *one* incorrect result when running under Valgrind. The
>> incorrect result is from HasRDRAND(). Under Valgrind, the result is 0,
>> which means RDRAND is not available.
>
> Valgrind deliberately "fakes" the results of CPUID so that the bits
> reflect the virtual machine that valgrind knows how to support.
> Valgrind does not know how to implement RDRAND.
> [Only Intel and very few others know *exactly* what RDRAND does.]
> A quick search of the web for "valgrind CPUID" will fill in the details.
> It's even documented: search for 'CPUID' or 'SSE2' in and below
> the docs/ directory of the source tree.
>