Hi! I used valgrind for checking sse4 code in 32-bit platform, so I got the message "vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x38 0x20". I clarified the problem and it turned out that valgrind couldn't recognize the instruction pmovsxbw in my code. I searched the internet, but didn't find any useful information on this point. Valgrind news announced in 2010 that there is initial support for such instructions in 64-bit mode , but it's 2014 already and no well-defined information for 32-bit is still available. When I decided to file a bug, I found this discussion https://bugs.kde.org/show_bug.cgi?id=291924 with one useful comment. There is a set of sse4 instructions and every time the person gets the message "unhandled instruction" he needs to spend a day to understand what's wrong. So, don't you think that it's a good idea to warn the user that such instructions are not handled in 32-bit mode or just specify this information on official valgrind site? Some people would be grateful for such notifications :) Thank you.
(In reply to comment #0) > So, don't you think that it's a good idea to warn the user that such > instructions are not handled in 32-bit mode or just specify this information > on official valgrind site? Some people would be grateful for such > notifications :) Yes, that looks a good idea. Where could we put that, so that it is (likely to be) found by people needing this info ? From what I can see, the fact that SSE4 is not (fully) supported on 32 bits is *already* in the user manual (and so, also on the valgrind website, which has a copy of the manual) : The 32 bits limited to SSE3 is in the first paragraph of the 'Limitations' section: http://www.valgrind.org/docs/manual/manual-core.html#manual-core.limits It is also somewhat documented in the NEWS file (search for SSE4). Maybe we could put a reference to the FAQ and the user manual limitation in the error msg: #define M(a) VG_(umsg)(a "\n"); M("Your program just tried to execute an instruction that Valgrind" ); M("did not recognise. There are two possible reasons for this." ); M("1. Your program has a bug and erroneously jumped to a non-code" ); M(" location. If you are running Memcheck and you just saw a" ); M(" warning about a bad jump, it's probably your program's fault."); M("2. The instruction is legitimate but Valgrind doesn't handle it,"); M(" i.e. it's Valgrind's fault. If you think this is the case or"); M(" you are not sure, please let us know and we'll try to fix it."); M("Either way, Valgrind will now raise a SIGILL signal which will" ); M("probably kill your program." ); #undef M
I like the idea of adding a FAQ link into the message. Another related idea: Whenever Valgrind says something like vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x38 0x20 I do ------------------- $ cat >foo.c void foo() { asm(".byte 0x66, 0xf, 0x38, 0x20, 0x0"); } ^D $ gcc -c -O2 foo.c && objdump -d foo.o 66 0f 38 20 00 pmovsxbw (%rax),%xmm0 ------------------- /* Please note Valgrind only prints out the first 4 bytes of the unhandled instruction, looks like this number should be raised to the maximum instruction length? */ I wonder if it's possible to automatically invoke something like objdump when an unhandled instruction happens? Then Valgrind can just say "hey, pmovsxbw is not handled, sorry". Otherwise, the FAQ entry should mention the above method. [adding my colleagues who fought similar problems before]
Yeah. I also like the idea to put FAQ link to error message. Btw, if it's possible to invoke objdump or something similar when "unhandled instructions" happen, it would be very helpful.
Have closed as wontfix two reports from OS X of unhandled SSE4.1 instructions in 32 bit. At the same time, referenced them here as am sure we will continue to get reports notwithstanding the tangential limitation expressed in the V manual.