Newest version 3.11 stopped handling some instruction. Version 3.10 works without any problems. Version 3.11 aborts application with message vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0xC7 0xF0 0x72 0x4 0xFF 0xC9 vex amd64->IR: REX=1 REX.W=1 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=0F vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==24113== valgrind: Unrecognised instruction at address 0x519ac23. ==24113== at 0x519AC23: poll_drng.isra.0 (in /usr/lib64/libgcrypt.so.20.0.3) ==24113== by 0x519AE6B: _gcry_rndlinux_gather_random (in /usr/lib64/libgcrypt.so.20.0.3) ==24113== by 0x51981FF: read_random_source (in /usr/lib64/libgcrypt.so.20.0.3) ==24113== by 0x51992AB: _gcry_rngcsprng_randomize (in /usr/lib64/libgcrypt.so.20.0.3) ==24113== by 0x5198074: _gcry_create_nonce (in /usr/lib64/libgcrypt.so.20.0.3) .... Reproducible: Always Steps to Reproduce: 1. Start application that uses gcrypt under Valgrind 3.11 2. 3. Actual Results: Valgrind fails to recognize instruction and issues SIGKILL Expected Results: Valgrind runs without any complaints I'm using gcc (Gentoo 4.8.5 p1.3, pie-0.6.2) 4.8.5 to compile binaries. The libraries are compiled with flags -march=native -O2 -pipe. My CPU model_name is Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
I suspect it's more likely that a change to the declared CPUID has caused your program to execute instructions it didn't try and execute before. The instruction here is RDRAND but with a REX prefix that sets REX.W to get 64 bit operation.
Hm. What do you mean with the "change to the declared CPUID"? Definitely I didn't change anything except for Valgrind. If I revert back to version 3.10 (which I did now) then things work. With version 3.11 Valgrind becomes unusable. After all, I don't really care what is causing this problem. I just would like to keep using newer versions of Valgrind and not get stuck with old one :) On Wed, Sep 30, 2015 at 3:58 PM, Tom Hughes <tom@compton.nu> wrote: > https://bugs.kde.org/show_bug.cgi?id=353370 > > Tom Hughes <tom@compton.nu> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |tom@compton.nu > > --- Comment #1 from Tom Hughes <tom@compton.nu> --- > I suspect it's more likely that a change to the declared CPUID has caused your > program to execute instructions it didn't try and execute before. > > The instruction here is RDRAND but with a REX prefix that sets REX.W to get 64 > bit operation. > > -- > You are receiving this mail because: > You reported the bug.
I mean that valgrind has potentially changed the CPU features that it advertises to your program - because it is a virtualised CPU it advertises one of a small number of standard feature sets rather than what your CPU natively declares.
Can you provide the following info: (1) cat /proc/cpuinfo (2) valgrind -d -v date 2> blah; grep hwcaps blah both for 3.10.x and 3.11.0
Created attachment 94790 [details] cpuinfo On Wed, Sep 30, 2015 at 5:25 PM, Florian Krohm <florian@eich-krohm.de> wrote: > valgrind -d -v date 2> blah; grep hwcaps blah See attached.
Created attachment 94791 [details] hwcaps.3_10
Created attachment 94792 [details] hwcaps.3_11
We seem to advertise RDRAND in cpuid: valgrind -q cpuid | grep RDRAND RDRAND instruction = true But cannot find where we implement it.
Since we don't implement RDRAND we shouldn't advertise it. Does the following patch help? diff --git a/priv/guest_amd64_helpers.c b/priv/guest_amd64_helpers.c index e77d753..ab53e15 100644 --- a/priv/guest_amd64_helpers.c +++ b/priv/guest_amd64_helpers.c @@ -3101,7 +3101,8 @@ void amd64g_dirtyhelper_CPUID_avx2 ( VexGuestAMD64State* st ) SET_ABCD(0x0000000d, 0x756e6547, 0x6c65746e, 0x49656e69); break; case 0x00000001: - SET_ABCD(0x000306c3, 0x02100800, 0x7ffafbff, 0xbfebfbff); + /* Don't advertise RDRAND support, bit 30 in ECX. */ + SET_ABCD(0x000306c3, 0x02100800, 0x3ffafbff, 0xbfebfbff); break; case 0x00000002: SET_ABCD(0x76036301, 0x00f0b6ff, 0x00000000, 0x00c10000);
On Thu, Oct 1, 2015 at 11:40 AM, Mark Wielaard <mjw@redhat.com> wrote: > guest_amd64_helpers.c Yes. this patch fixes the problem. Thank you
Thanks for reporting and checking. Fix pushed as VEX svn r3197
*** Bug 357873 has been marked as a duplicate of this bug. ***
*** Bug 358988 has been marked as a duplicate of this bug. ***
*** Bug 365325 has been marked as a duplicate of this bug. ***
*** Bug 375845 has been marked as a duplicate of this bug. ***
*** Bug 378180 has been marked as a duplicate of this bug. ***
*** Bug 381699 has been marked as a duplicate of this bug. ***
*** Bug 387940 has been marked as a duplicate of this bug. ***
*** Bug 395809 has been marked as a duplicate of this bug. ***
*** Bug 396176 has been marked as a duplicate of this bug. ***
*** Bug 400279 has been marked as a duplicate of this bug. ***
*** Bug 401846 has been marked as a duplicate of this bug. ***
I'm seeing this with valgrind-3.15.0, even though the release notes say RdRand is now supported. The system is compiled with -march=native on an “Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz”. -- $ valgrind scribus ==26338== Memcheck, a memory error detector ==26338== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==26338== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==26338== Command: scribus ==26338== vex amd64->IR: unhandled instruction bytes: 0xF 0xC7 0xF0 0xB9 0x1 0x0 0x0 0x0 0x89 0x3 vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=0F vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==26338== valgrind: Unrecognised instruction at address 0x8769603. ==26338== at 0x8769603: _rdrand32_step (immintrin.h:138) ==26338== by 0x8769603: qt_random_cpu (qrandom.cpp:114) ==26338== by 0x8769603: QRandomGenerator::SystemGenerator::generate(unsigned int*, unsigned int*) (qrandom.cpp:370) ==26338== by 0x87BC11A: fillRange<unsigned int> (qrandom.h:143) ==26338== by 0x87BC11A: generate (qrandom.h:87) ==26338== by 0x87BC11A: qt_create_qhash_seed() (qhash.cpp:299) ==26338== by 0x87BC1D4: qt_initialize_qhash_seed (qhash.cpp:325) ==26338== by 0x87BC1D4: qt_initialize_qhash_seed() (qhash.cpp:322) ==26338== by 0x87BC7C9: QHashData::detach_helper(void (*)(QHashData::Node*, void*), void (*)(QHashData::Node*), int, int) (qhash.cpp:502) ==26338== by 0x87CFDB9: QHash<QRegExpEngineKey, QCache<QRegExpEngineKey, QRegExpEngine>::Node>::detach_helper() [clone .isra.191] (qhash.h:599) ==26338== by 0x87D5FFB: detach (qhash.h:275) ==26338== by 0x87D5FFB: find (qhash.h:901) ==26338== by 0x87D5FFB: take (qcache.h:154) ==26338== by 0x87D5FFB: prepareEngine_helper(QRegExpPrivate*) (qregexp.cpp:3853) … -- http://www.valgrind.org/docs/manual/dist.news.html Release 3.15.0 (12 April 2019) * amd64 (x86_64): the RDRAND and F16C insn set extensions are now supported.
That's badly written - they are not supported but this bug is resolved by making valgrind's emulation of the cpuid instruction remove the bit which claims support for them. So an application which tests for rdrand before using it will now work but one which just assumes it can use it will still fail.
So actually there is a later commit which does actually implement RDRAND but only for AVX2 capable CPUs which yours is not. My other point remains correct, that we won't advertise RDRAND on any machine where we don't support it. The reason by the way that we only do it for AVX2 capable CPUs is that we only support a limited set of CPU profiles and the next one down is: Intel(R) Core(TM) i5-2300 CPU @ 2.80GHz which is not RDRAND capable.
(In reply to Tom Hughes from comment #25) > So actually there is a later commit which does actually implement RDRAND but > only for AVX2 capable CPUs which yours is not. I think Mark just fixed it to work on AVX-only capable CPUs too. See bug 408009.
That doesn't invalidate Tom's comment though: you should always test with CPUID at run time for the presence of any particular instruction set extension, before using it. Especially for recent or obscure extensions.
That latest change isn't actually committed yet ;-)
It is now. And seems to work, thanks.