We can't use valgrind on 64bit Opteron (RHEE3) because valgrind gives up when it sees this instruction (which should be OK). Here's the entire snippet. ncsim> run 10000ns ==12363== Warning: client switching stacks? SP change: 0x7FEFF9FD0 --> 0x5908C00 ==12363== to suppress, use: --max-stackframe=-110160944 or greater vex amd64->IR: unhandled instruction bytes: 0x49 0xDD 0x86 0xE0 ==12363== valgrind: Unrecognised instruction at address 0x55D46E9. ==12363== Your program just tried to execute an instruction that Valgrind ==12363== did not recognise. There are two possible reasons for this. ==12363== 1. Your program has a bug and erroneously jumped to a non-code ==12363== location. If you are running Memcheck and you just saw a ==12363== warning about a bad jump, it's probably your program's fault. ==12363== 2. The instruction is legitimate but Valgrind doesn't handle it, ==12363== i.e. it's Valgrind's fault. If you think this is the case or ==12363== you are not sure, please let us know and we'll try to fix it. ==12363== Either way, Valgrind will now raise a SIGILL signal which will ==12363== probably kill your program. ncsim: *F,INTERR: INTERNAL ERROR Observed simulation time : 0 FS + 0 ----------------------------------------------------------------- The tool has encountered an unexpected condition and must exit. Contact Cadence Design Systems customer support about this problem and provide enough information to help us reproduce it, including the logfile that contains this error message. TOOL: ncsim(64) 06.01-a001 HOSTNAME: sdvopt18 OPERATING SYSTEM: Linux 2.4.21-37.ELsmp #1 SMP Wed Sep 7 13:32:18 EDT 2005 x86_64 MESSAGE: sv_illhandler - SIGILL/SIGTRAP not in_rts_xfer (4) ----------------------------------------------------------------- ==12363== ==12363== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 3 from 2) ==12363== malloc/free: in use at exit: 7,076,585 bytes in 6,603 blocks. ==12363== malloc/free: 11,377 allocs, 4,774 frees, 11,775,896 bytes allocated. ==12363== For a detailed leak analysis, rerun with: --leak-check=yes ==12363== For counts of detected errors, rerun with: -v ncsc_run: *E,TBSIMF: ncsim returned non-zero exit status
This isn't really a valid instruction. It is "fldl 0xe0(%r14)" but with a redundant REX.W prefix bit set. (ie an 0x41 prefix is right; 0x49 isn't). My amd64 box executes it without complaint. Did this bit of code get made by a GNU toolchain, or by something else?
George, what does 'as --version' give?
[georgef@ncopt09 bin]$ ./as --version GNU assembler 2.14.90.0.4 20030523 Copyright 2002 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of `x86_64-redhat-linux'. -----Original Message----- From: owner@bugs.kde.org [mailto:owner@bugs.kde.org] On Behalf Of Julian Seward Sent: Saturday, November 18, 2006 5:15 PM To: George Frazier Subject: [Bug 135023] vex amd64->IR: unhandled instruction bytes: 0x49 0xDD 0x86 0xE0 ------- You are receiving this mail because: ------- You reported the bug, or are watching the reporter. http://bugs.kde.org/show_bug.cgi?id=135023 ------- Additional Comments From jseward acm org 2006-11-19 00:15 ------- George, what does 'as --version' give?
Using valgrind 3.5.0, I was able to work around this issue by commenting out the check "&& redundantREXWok" in VEX/priv/guest_amd64_toIR.c.