| Summary: | unhandled instruction "popcnt" (arch=amd10h) | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Thomas Eschenbacher <Thomas.Eschenbacher> |
| Component: | general | Assignee: | Julian Seward <jseward> |
| Status: | REOPENED --- | ||
| Severity: | normal | CC: | jonghyun.lee, luke-jr+kdebugs, nunoplopes, philippe.waroquiers, pjfloyd, tom |
| Priority: | NOR | ||
| Version First Reported In: | 3.9.0 | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | patch to add support for the SSE4.2 instruction "popcnt" for X86 | ||
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. *** |
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 [...]