Bug 135023 - vex amd64->IR: unhandled instruction bytes: 0x49 0xDD 0x86 0xE0
Summary: vex amd64->IR: unhandled instruction bytes: 0x49 0xDD 0x86 0xE0
Alias: None
Product: valgrind
Classification: Developer tools
Component: vex (show other bugs)
Version: 3.2.1
Platform: Unlisted Binaries Linux
: NOR crash
Target Milestone: ---
Assignee: Julian Seward
Depends on:
Blocks: 253451
  Show dependency treegraph
Reported: 2006-10-03 00:34 UTC by George Frazier
Modified: 2010-11-11 19:51 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description George Frazier 2006-10-03 00:34:13 UTC
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 --> 
==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.
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 
  MESSAGE: sv_illhandler - SIGILL/SIGTRAP not in_rts_xfer (4)
==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
Comment 1 Julian Seward 2006-11-12 22:20:55 UTC
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
Comment 2 Julian Seward 2006-11-19 00:15:09 UTC
George, what does 'as --version' give?
Comment 3 George Frazier 2007-01-16 23:36:30 UTC
[georgef@ncopt09 bin]$ ./as --version
GNU assembler 20030523
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
the GNU General Public License.  This program has absolutely no
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
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.

------- Additional Comments From jseward acm org  2006-11-19 00:15
------- George, what does 'as --version' give?
Comment 4 Mark Harris 2009-10-30 05:22:53 UTC
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.