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: | vex | Assignee: | 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
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) |