I am trying to run a basic x86 binary on my amd64 machine in valgrind. I get the folling output: vex x86->IR: unhandled instruction bytes: 0xC5 0xF9 0x6E 0x40 ==19987== valgrind: Unrecognised instruction at address 0x4414650. ==19987== at 0x4414650: _dl_sysdep_start (in /lib32/ld-2.14.1.so) ==19987== by 0x4404DD7: _dl_start (in /lib32/ld-2.14.1.so) ==19987== by 0x44012C6: ??? (in /lib32/ld-2.14.1.so) Disassembly of the bytes is: vmovd xmm0,DWORD PTR [eax+0x0]. Seems that on my machine, there are some strange SSE instructions in the basic libraries that are not handled my valgrind. Reproducible: Always Steps to Reproduce: echo "int main(void) {return 0;}" > ./hello.c gcc -m32 -o ./hello ./hello.c valgrind ./hello Actual Results: ==20111== Memcheck, a memory error detector ==20111== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==20111== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==20111== Command: ./hello ==20111== vex x86->IR: unhandled instruction bytes: 0xC5 0xF9 0x6E 0x40 ==20111== valgrind: Unrecognised instruction at address 0x4414650. ==20111== at 0x4414650: _dl_sysdep_start (in /lib32/ld-2.14.1.so) ==20111== by 0x4404DD7: _dl_start (in /lib32/ld-2.14.1.so) ==20111== by 0x44012C6: ??? (in /lib32/ld-2.14.1.so) ==20111== Your program just tried to execute an instruction that Valgrind ==20111== did not recognise. There are two possible reasons for this. ==20111== 1. Your program has a bug and erroneously jumped to a non-code ==20111== location. If you are running Memcheck and you just saw a ==20111== warning about a bad jump, it's probably your program's fault. ==20111== 2. The instruction is legitimate but Valgrind doesn't handle it, ==20111== i.e. it's Valgrind's fault. If you think this is the case or ==20111== you are not sure, please let us know and we'll try to fix it. ==20111== Either way, Valgrind will now raise a SIGILL signal which will ==20111== probably kill your program. ==20111== ==20111== Process terminating with default action of signal 4 (SIGILL) ==20111== Illegal opcode at address 0x4414650 ==20111== at 0x4414650: _dl_sysdep_start (in /lib32/ld-2.14.1.so) ==20111== by 0x4404DD7: _dl_start (in /lib32/ld-2.14.1.so) ==20111== by 0x44012C6: ??? (in /lib32/ld-2.14.1.so) ==20111== ==20111== HEAP SUMMARY: ==20111== in use at exit: 0 bytes in 0 blocks ==20111== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==20111== ==20111== All heap blocks were freed -- no leaks are possible ==20111== ==20111== For counts of detected and suppressed errors, rerun with: -v ==20111== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Illegal instruction Expected Results: ==20111== Memcheck, a memory error detector ==20111== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==20111== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==20111== Command: ./hello ==20111== ==20111== ==20111== HEAP SUMMARY: ==20111== in use at exit: 0 bytes in 0 blocks ==20111== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==20111== ==20111== All heap blocks were freed -- no leaks are possible ==20111== ==20111== For counts of detected and suppressed errors, rerun with: -v ==20111== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6) My default CFLAGS are "-O2 -pipe -fomit-frame-pointer -march=bdver1 -mcx16 -msahf -mno-movbe -maes -mpclmul -mpopcnt -mabm -mlwp -mno-fma -mfma4 -mxop -mno-bmi -mno-tbm -mavx -msse4.2 -msse4.1 --param l1-cache-size=16 --param l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=bdver1". I compie everything with gcc 4.6.2. My uname -a is Linux raven 3.2.12 #5 SMP Tue Apr 3 16:37:44 CEST 2012 x86_64 AMD FX(tm)-8150 Eight-Core Processor AuthenticAMD GNU/Linux
This also occurs in the current svn (revision 12639).
*** This bug has been marked as a duplicate of bug 273475 ***
Reopening. This isn't a dup of the canonical-AVX bug (273475) because this is happening in the 32 bit front end. That said .. it's unlikely that the 32-bit front end will ever support AVX. If you want to do AVX, please use 64-bit code.
Why don't just include the 64-bit AVX part into the 32-bit frontend?
I am experiencing the same problem. As far as I understand the only reason it is not going to be implemented is a lack of developers wanting to do it? Or are there any other hidden reasons?
I would also welcome x86 AVX support.
her are my 2 cts : I just tried to debug trinity under a 32 bit Gentoo Linux : $ valgrind --leak-check=yes trinity --children 4 --victims /mnt/n22/w/victims -N 50000 --quiet -c vmsplice ==1065== Memcheck, a memory error detector ==1065== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==1065== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==1065== Command: trinity --children 4 --victims /mnt/n22/w/victims -N 50000 --quiet -c vmsplice ==1065== vex x86->IR: unhandled instruction bytes: 0xC5 0xF9 0x6E 0x40 ==1065== valgrind: Unrecognised instruction at address 0x40149a0. ==1065== at 0x40149A0: _dl_sysdep_start (in /lib/ld-2.15.so) ==1065== by 0xFFF: ??? ==1065== Your program just tried to execute an instruction that Valgrind ==1065== did not recognise. There are two possible reasons for this. ==1065== 1. Your program has a bug and erroneously jumped to a non-code ==1065== location. If you are running Memcheck and you just saw a ==1065== warning about a bad jump, it's probably your program's fault. ==1065== 2. The instruction is legitimate but Valgrind doesn't handle it, ==1065== i.e. it's Valgrind's fault. If you think this is the case or ==1065== you are not sure, please let us know and we'll try to fix it. ==1065== Either way, Valgrind will now raise a SIGILL signal which will ==1065== probably kill your program. ==1065== ==1065== Process terminating with default action of signal 4 (SIGILL): dumping core ==1065== Illegal opcode at address 0x40149A0 ==1065== at 0x40149A0: _dl_sysdep_start (in /lib/ld-2.15.so) ==1065== by 0xFFF: ??? ==1065== ==1065== HEAP SUMMARY: ==1065== in use at exit: 0 bytes in 0 blocks ==1065== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==1065== ==1065== All heap blocks were freed -- no leaks are possible ==1065== ==1065== For counts of detected and suppressed errors, rerun with: -v ==1065== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Illegal instruction
I also follow this feature request. My unhandled instruction is: vex x86->IR: unhandled instruction bytes: 0xC5 0xF9 0xEF 0xC0 ==5032== valgrind: Unrecognised instruction at address 0x400b80c. Thanks in advance.
same problem with AVX on x86 (androi-ia from 01.org on haswell-U CPU): vex x86->IR: unhandled instruction bytes: 0xC5 0xFA 0x7E 0x40 ==5893== valgrind: Unrecognised instruction at address 0x400cbf8. ==5893== at 0x400CBF8: __dl_memcpy (in /system/bin/linker) ==5893== by 0x483059F: ??? or vex x86->IR: unhandled instruction bytes: 0xC4 0xE2 0x79 0xF7 ==6006== valgrind: Unrecognised instruction at address 0x808dc7b. ==6006== at 0x808DC7B: pthread_key_create (pthread_key.cpp:128) ==6006== by 0x8048F56: __bionic_tls_basename_key_init() (libgen.cpp:39) ==6006== by 0x808DFE1: __libc_init (libc_init_static.cpp:65) ==6006== by 0x804926E: _start (in /init)
This still replicates in $ valgrind --version valgrind-3.10.1 The work-around for "use 64-bit code" isn't really an option for me.
FWIW, I encountered this combination on MacOS 10.10, but only when compiling for 32bit, with valgrind-3.11.0.SVN from fink: vex x86->IR: unhandled instruction bytes: 0xC5 0xFA 0x10 0x44 ==14328== valgrind: Unrecognised instruction at address 0x1677a44. ==14328== at 0x1677A44: cosh$fenv_access_off (in /usr/lib/system/libsystem_m.dylib)