Version: unspecified (using KDE 4.6.2) OS: Linux Here some output of an attempt to run my application with cachegrind: [...] # --5039-- Reading syms from /usr/lib/libfontconfig.so.1.4.4 (0x4279000) [...] vex x86->IR: unhandled instruction bytes: 0xF3 0xF 0xB8 0x14 ==5039== valgrind: Unrecognised instruction at address 0x42836c8. ==5039== Your program just tried to execute an instruction that Valgrind ==5039== did not recognise. There are two possible reasons for this. ==5039== 1. Your program has a bug and erroneously jumped to a non-code ==5039== location. If you are running Memcheck and you just saw a ==5039== warning about a bad jump, it's probably your program's fault. ==5039== 2. The instruction is legitimate but Valgrind doesn't handle it, ==5039== i.e. it's Valgrind's fault. If you think this is the case or ==5039== you are not sure, please let us know and we'll try to fix it. ==5039== Either way, Valgrind will now raise a SIGILL signal which will ==5039== probably kill your program. ==5039== ==5039== Process terminating with default action of signal 4 (SIGILL) ==5039== Illegal opcode at address 0x42836C8 ==5039== at 0x42836C8: FcCharSetCount (in /usr/lib/libfontconfig.so.1.4.4) => offset within libfontconfig therefore seems to be 0x42836C8 - 0x4279000 = 0xA6C8 When disassembling this lib with "objdump -d" I see this instruction: a6c8: f3 0f b8 14 01 popcnt (%ecx,%eax,1),%edx So I conclude that support for the "popcnt" instruction is missing. Reproducible: Didn't try $ valgrind --version valgrind-3.6.1 $ gcc --version gcc (Gentoo 4.5.2 p1.1, pie-0.4.5) 4.5.2 $ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 5 model name : AMD Athlon(tm) II X4 615e Processor stepping : 3 [...]
This was implemented in VEX r1983.
sorry, but this is still not fixed. I tried again with svn r12257 from today, which announces itself as "Valgrind-3.8.0.SVN and LibVEX" vex x86->IR: unhandled instruction bytes: 0xF3 0xF 0xB8 0xD2 4b16a20d: f3 0f b8 d2 popcnt %edx,%edx
Ah that commit was only for 64 bit mode and you're in 32 bit mode.
Hi, now nearly one year passed, but the problem still persists, valgrind (v3.8.1 / 32bit mode) still is practically unusable for me :-( Any chance to get this fixed ?
Created attachment 74970 [details] patch to add support for the SSE4.2 instruction "popcnt" for X86
ok, seems that nobody else had time for this... So I tried to fix it on my own and wrote a patch for it (see attachment), which seems to work for me. => Could someone of the developers please review it?
Apparently this patch has not been taken into v3.9.0 - why? Please integrate it in the next release! (the patch file above can be still applied)
(In reply to comment #7) > Apparently this patch has not been taken into v3.9.0 - why? > Please integrate it in the next release! > (the patch file above can be still applied) Personnally, I cannot commit this patch as I do not know this part of Valgrind, and so cannot judge if it is ok or not. But I think the patch has more chance to be looked at (by others :) if there is a test case. Philippe
Ok, you want a test case, here it is a simple one: ;-) 1. create a simple program "poptest.c": int main(int argc, char **argv) { return __builtin_popcount(argc + *argv[0]); } 2. compile it: $> gcc -mpopcnt poptest.c -o poptest 3. verify that it contains a popcnt instruction: $> objdump -d poptest should give something like this: [...] 0804842c <main>: 804842c: 55 push %ebp 804842d: 89 e5 mov %esp,%ebp 804842f: 8b 45 0c mov 0xc(%ebp),%eax 8048432: 8b 00 mov (%eax),%eax 8048434: 0f b6 00 movzbl (%eax),%eax 8048437: 0f be d0 movsbl %al,%edx 804843a: 8b 45 08 mov 0x8(%ebp),%eax 804843d: 01 d0 add %edx,%eax 804843f: f3 0f b8 c0 popcnt %eax,%eax <= here it is ! 8048443: 5d pop %ebp 8048444: c3 ret [...] 4. and finally, try to analyze it with valgrind: $> valgrind ./poptest
(In reply to comment #9) > Ok, you want a test case, here it is a simple one: ;-) That was quick. Note however that the best way to provide a test is to conform to the technique used to write the currently existing tests see e.g. none/tests/x86/lzcnt32.* or /none/tests/amd64/sse4-64.* A better test might motivate better someone with a better knowledge of ss4 than me :)
*** Bug 349891 has been marked as a duplicate of this bug. ***