Bug 301967

Summary: vex x86->IR: unhandled instruction bytes 0xC5 0xF9 0x6E 0x40 in /lib32/ld-2.14.1.so
Product: [Developer tools] valgrind Reporter: Markus Fenske <iblue>
Component: vexAssignee: Julian Seward <jseward>
Status: REOPENED ---    
Severity: normal CC: abel.bernabeu, aospan, arkangath, default_357-line, jadamcze, janisozaur+kde, luke-jr+kdebugs, realnc, sam, schwarz, tom, toralf.foerster, voidwrk
Priority: NOR    
Version: 3.7.0   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Markus Fenske 2012-06-15 12:46:07 UTC
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
Comment 1 Markus Fenske 2012-06-15 13:01:14 UTC
This also occurs in the current svn (revision 12639).
Comment 2 Tom Hughes 2012-06-15 14:02:49 UTC

*** This bug has been marked as a duplicate of bug 273475 ***
Comment 3 Julian Seward 2012-07-04 12:21:11 UTC
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.
Comment 4 Markus Fenske 2012-07-04 17:25:20 UTC
Why don't just include the 64-bit AVX part into the 32-bit frontend?
Comment 5 Sergey Kishchenko 2012-11-02 16:58:01 UTC
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?
Comment 6 FeepingCreature 2013-02-12 14:03:30 UTC
I would also welcome x86 AVX support.
Comment 7 Toralf Förster 2013-04-18 16:58:24 UTC
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
Comment 8 Abel Bernabeu 2013-04-22 17:04:50 UTC
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.
Comment 9 aospan 2014-07-23 09:45:02 UTC
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)
Comment 10 Pedro Ferreira 2015-04-02 08:57:33 UTC
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.
Comment 11 diemo 2015-09-10 17:02:24 UTC
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)