Bug 135023

Summary: vex amd64->IR: unhandled instruction bytes: 0x49 0xDD 0x86 0xE0
Product: [Developer tools] valgrind Reporter: George Frazier <georgef>
Component: vexAssignee: Julian Seward <jseward>
Status: REPORTED ---    
Severity: crash CC: markh, njn
Priority: NOR    
Version: 3.2.1   
Target Milestone: ---   
Platform: Unlisted Binaries   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Bug Depends on:    
Bug Blocks: 253451    

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 --> 
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
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
else?
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 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?
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.