Version: (using KDE Devel) Installed from: Compiled sources Compiler: gcc-3.4.6 OS: Linux Hello, I'm having problem running valgrind 3.x on programs compiled for my native CPU. The problem is getting illegal instruction signal on instructions like CMOV and it seems it is caused by wrong detection of my CPU. To check this I used cpuinfo.c program from mplayerhq.hu, that gives output similar to /proc/cpuinfo. ( #instructions to quickly get cpuinfo.c mkdir cpuinfo svn co svn://svn.mplayerhq.hu/mplayer/trunk/TOOLS/ gcc TOOLS/cpuinfo.c -o cpuinfo ) valgrind 3.0.1 , valgrind 3.2.1 and just compiled current valgrind svn r6555 (VEX r1731), all produce same result: ================ valgrind 3.x.x ---------------- $ valgrind ./cpuinfo vendor_id : GenuineIntel cpu family : 5 model : 4 stepping : 3 flags : fpu vme de pse tsc msr mce cx8 mmx cpu MHz : 1005.421 model name : Unknown GenuineIntel CPU The last version of valgrind 2.x however emulates my CPU correctly. ================= valgrind 2.4.0 ----------------- $ valgrind ./cpuinfo vendor_id : AuthenticAMD cpu family : 6 model : 4 stepping : 2 flags : fpu vme de pse tsc pae mce cx8 mtrr pge mca cmov pat pse36 mmx fxsr mmxext cpu MHz : 1004.483 model name : AMD Athlon(tm) processor ---- ================ host CPU ---------------- $ ./cpuinfo vendor_id : AuthenticAMD cpu family : 6 model : 4 stepping : 2 flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dn owext 3dnow cpu MHz : 1000.094 model name : AMD Athlon(tm) processor $ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 4 model name : AMD Athlon(tm) processor stepping : 2 cpu MHz : 1000.077 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dn owext 3dnow bogomips : 2001.93 ---- I have no idea why my Athlon is detected as one generation older Pentium MMX. But newer valgrind should support more CPU's not less. Just for the record. I'm compiling and creating package, that is then installed and/or upgraded to the another valgrind package, so I am sure there are no left-over files. I think the default --tool is memcheck. I'm using valgrind.rc file that output to a log file, so here is raw output of the svn valgrind3 , without any config files. ================ $ valgrind cpuinfo ==11868== Memcheck, a memory error detector. ==11868== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==11868== Using LibVEX rev 1731, a library for dynamic binary translation. ==11868== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==11868== Using valgrind-3.3.0.SVN, a dynamic binary instrumentation framework. ==11868== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==11868== For more details, rerun with: -v ==11868== --11868-- DWARF2 CFI reader: unhandled CFI instruction 0:50 --11868-- DWARF2 CFI reader: unhandled CFI instruction 0:50 vendor_id : GenuineIntel cpu family : 5 model : 4 stepping : 3 flags : fpu vme de pse tsc msr mce cx8 mmx cpu MHz : 1004.700 model name : Unknown GenuineIntel CPU ==11868== ==11868== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 11 from 1) ==11868== malloc/free: in use at exit: 0 bytes in 0 blocks. ==11868== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. ==11868== For counts of detected errors, rerun with: -v ==11868== All heap blocks were freed -- no leaks are possible.
Valgrind provides a simulated x86 cpu - there is no guarantee that the CPU it simulates is exactly the same as the physical CPU is it executing on although the two will be broadly similar. In version 2 we use to pass through the CPUID results more or less unmolested, to the point where it might even report support for instructions that weren't really supported at all. In version 3 the CPUID results are more or less completely fake and are intended to describe the actual virtual CPU being provided by valgrind. The problem here is not CPU detection, but a failure to implement certain instructions that you happen to want - if you report those missing instructions by raising bugs for them then hopefully we can get them implemented.
I wrote that I get "Invalid operation" on CMOV, that is i686 specific instruction, while valgrind 3.x emulates i586. I do not have problems debuging code containing CMOV, MMX-EXT, 3Dnow, 3Dnow!Ex when using valgrind 2.x. From your answer I could conclude that valgrind 3.x is only capable of emulating i586 Pentium MMX!! Valgrind 3.x claims AMD64 support and it have all Athlon instructions (plus a lot more). The only logical explanation is that valgrind is thinking I do have i586 class CPU and limits its features to match it. (btw I had similar bug - http://bugs.kde.org/show_bug.cgi?id=85947 , this time it is just a lot more worse):
As I explained, valgrind 3 does not emulate the exact CPU it is running on. Instead it groups CPUs into broad classes and emulates a basic CPU of that class. Those classes (for x86) are SSE0 (ie a basic old style x86 CPU), SSE1, SSE2 and SSE3. Unfortunately what you have is between SSE0 and SSE1 in that it has MMX and MMXEXT but not the full SSE1 instruction set. As a result it is reduced to the SSE0 level and nothing much more than basic i386 instructions will be emaulated. Julian - I notice that the CPU features in VEX are now a bitmask, so perhaps we could have bits for CMOV, MMX and MMXEXT and then enable the relevant instructions when appropriate? I think that would solve this bug.
I have related problem on: processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 3 model name : AMD Duron(tm) processor stepping : 1 cpu MHz : 951.751 cache size : 64 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow bogomips : 1903.50 clflush size : 32 cache_alignment : 32 address sizes : 36 bits physical, 32 bits virtual power management: I get following SIGABORT when running valgrind-3.5.0 or 3.6.0: $ valgrind /usr/bin/uname ==19853== Memcheck, a memory error detector ==19853== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==19853== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==19853== Command: /usr/bin/uname ==19853== uname: ../sysdeps/x86_64/cacheinfo.c:255: handle_intel: Assertion `maxidx >= 2' failed. ==19853== ==19853== HEAP SUMMARY: ==19853== in use at exit: 89 bytes in 1 blocks ==19853== total heap usage: 2 allocs, 1 frees, 189 bytes allocated ==19853== ==19853== LEAK SUMMARY: ==19853== definitely lost: 0 bytes in 0 blocks ==19853== indirectly lost: 0 bytes in 0 blocks ==19853== possibly lost: 0 bytes in 0 blocks ==19853== still reachable: 89 bytes in 1 blocks ==19853== suppressed: 0 bytes in 0 blocks ==19853== Rerun with --leak-check=full to see details of leaked memory ==19853== ==19853== For counts of detected and suppressed errors, rerun with: -v ==19853== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 7 from 7) Aborted I found this problem in Gentoo with glibc-2.11.2. I found supposed solution in Debian bug tracking system <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584912>, however the SVN snapshot (r11254) used in Debian is not in current trunk branch, nor valgrind compiled from Debian sources fixes it. Any suggestions?
We believe this bug may be the same one we hit in Gentoo: http://bugs.gentoo.org/show_bug.cgi?id=345873 and was hit in Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584912 Message #60 of the Debian bug has an explanation for what's going on. They seem to think its fixed, but we could not confirm that.