On 23.01.2012 22:59, John Reiser wrote: > Probably there is an unexpected interaction between the code in glibc > which does processor detection using CPUID (etc.), and the code in > valgrind which delivers "synthetic" results for CPUID. Both valgrind > and glibc might need to be more robust. I just compiled glibc with -mno-avx and tried to shoot valgrind again. Now libstdc++ turns out to be the problem:
vex x86->IR: unhandled instruction bytes: 0xC5 0xF9 0x6E 0x44 ==2297== valgrind: Unrecognised instruction at address 0x5358a90. ==2297== at 0x5358A90: std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::_M_sync(char*, unsigned int, unsigned int) (in /usr/lib32/libstdc++.so.6.0.16) > Look in the disassembly for 'cpuid'. File a bug report against valgrind > at https://bugs.kde.org/ . Include the complete disassembly of > _dl_sysdep_start, and the name and version of your Linux and glibc. The _dl_sysdep_start dump does not contain cpuid. However, ld.so does: $ objdump /usr/lib64/debug/lib32/ld-2.13.so.debug -D | grep cpuid 23092: 0f a2 cpuid 35b4c: 0f a2 cpuid Bug report: https://bugs.kde.org/show_bug.cgi?id=292300 -- Mierswa, Daniel If you still don't like it, that's ok: that's why I'm boss. I simply know better than you do. --- Linus Torvalds, comp.os.linux.advocacy, 1996/07/22 ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
