Summary: | Wrong CPU detection of Athlon | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | Ivan Kalvachev <iive> |
Component: | general | Assignee: | Julian Seward <jseward> |
Status: | REPORTED --- | ||
Severity: | normal | CC: | blueness, petr.pisar |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Ivan Kalvachev
2007-01-27 19:10:39 UTC
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. |