Version: unspecified OS: OS X This is the report I get from valgrind: vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x3A 0xA ==94567== valgrind: Unrecognised instruction at address 0x727902. Happens fairly universally when I try to run valgrind on many common MacOS binaries. seems to be triggered by calls to "floorf$fenv_access_off" and similar. Reproducible: Didn't try Steps to Reproduce: use valgrind on any GUI-using binaries on 10.6. firefox or thunderbird do the trick.
This is the roundss SSE4 instruction.
There is a related report for roundsd in bug #197266.
I suppose then, based on the previous report, no quick workaround to this? Rounding op is pretty common (used in system library), evidently so this precludes Valgrind from working on anything application that uses floating point under OS X 10.6
John Grabowski from Chromium team reports the same bug on 10.6, see http://code.google.com/p/chromium/issues/detail?id=46947
(In reply to comment #3) > so this > precludes Valgrind from working on anything application that uses floating > point under OS X 10.6 That's not exactly correct -- it only is a problem on Core iX processors and later model Core 2's (Core 2 8xxx). Anyway, I have been working through SSE4 instructions recently and will look at implementing ROUNDxx next.
Just for the record: we've built Valgrind r11195 (after the MACOSX106 merge), but the error reported at http://code.google.com/p/chromium/issues/detail?id=46947 is still there. Looks like the Chromium test calls _ceilf() from /usr/lib/libSystem.B.dylib, which has the following implementation on that machine: 00059350 <_ceilf>: 59350: f3 0f 10 44 24 04 movss 0x4(%esp),%xmm0 59356: f7 05 20 00 ff ff 00 testl $0x400,0xffff0020 5935d: 04 00 00 59360: 74 1e je 59380 <_ceilf+0x30> 59362: 66 0f 3a 0a c0 02 roundss $0x2,%xmm0,%xmm0 59368: f3 0f 11 44 24 04 movss %xmm0,0x4(%esp) 5936e: d9 44 24 04 flds 0x4(%esp) 59372: c3 ret 59373: 66 0f 1f 44 00 00 nopw 0x0(%eax,%eax,1) 59379: 0f 1f 80 00 00 00 00 nopl 0x0(%eax) 59380: 8b 44 24 04 mov 0x4(%esp),%eax 59384: b1 17 mov $0x17,%cl 59386: 89 c2 mov %eax,%edx 59388: d3 e8 shr %cl,%eax ... For some strange reason Valgrind still complains about the roundss insruction (0x66 0xF 0x3A 0xA) in this function, although it doesn't in a small binary that just executes roundss. I'm working on a stable reproducer for this.
(In reply to comment #6) > Just for the record: we've built Valgrind r11195 (after the MACOSX106 merge), > but the error reported at > http://code.google.com/p/chromium/issues/detail?id=46947 is still there. You are running a 32-bit executable. The fix I made is for 64-bit only (so far, all SSE4 support is 64-bit only, due to time constraints). Try again as a 64-bit process. 64-bit MACOSX support now works pretty well so there is no reason not to use it.
(In reply to comment #7) > You are running a 32-bit executable. The fix I made is for 64-bit only > (so far, all SSE4 support is 64-bit only, due to time constraints). Try > again as a 64-bit process. 64-bit MACOSX support now works pretty well > so there is no reason not to use it. Unfortunately we don't support 64-bit builds of Chromium on Mac yet. Am I understanding you right that SSE4 could be implemented for 32-bit in the same way?
This is an issue for other applications/projects/developers as well -- unfortunately, building 64-bit is not an option for several of the projects I work on, which still need to link against some 32-bit-only system frameworks and use some 32-bit-only APIs. So, if there's a fast path to making SSE4 work for 32-bit executables as well, that would be great.
> Am I understanding you right that SSE4 could be implemented for 32-bit in the > same way? Yes. It would take some work though, which is why I had hoped to complete the SSE4 instructions for 64-bit mode before extending it to 32-bit mode.
(In reply to comment #9) > and use some 32-bit-only APIs. So, if there's a fast path to making SSE4 work > for 32-bit executables as well, that would be great. I suspect only a relatively small subset of SSE4 would be needed for 32-bit SSE4 support on 10.6. I only have access to a SSSE3 capable machine for 10.6, so I can't test this. If anyone is happy to provide a ssh login on a SSE4 capable 10.6 box, I could at least make a preliminary assessment of what needs to be done.
(In reply to comment #11) > I suspect only a relatively small subset of SSE4 would be needed for 32-bit > SSE4 support on 10.6. I only have access to a SSSE3 capable machine for > 10.6, so I can't test this. If anyone is happy to provide a ssh login on > a SSE4 capable 10.6 box, I could at least make a preliminary assessment > of what needs to be done. It looks like any machine manufactured after mid-2008 would qualify; as far as I can tell, SSE4 was introduced with Penryn. I'll see if I can find something to get you an account on. :-) Meanwhile, what do you have access to today?
Well, SSE4 was introduced in two parts, SSE4.1 and SSE4.2. 4.1 became available on 45nm Core 2's, that is, Core 2 E8xxx. 4.2 became available on Core iX. For running MacOS I only have an older Core2 E6xxx so I'm pretty sure it won't even do 4.1.
Fixed (vex r1987). At least, this provides support for roundss in 32-bit mode, so that calls to floorf now succeed.
*** Bug 236546 has been marked as a duplicate of this bug. ***
It does not seem to be completely fixed. I'm getting this error in Ogre3D for MAC OSX. Ogre3D runs only in 32 bit mode. valgrind svn as of 30-08-2010, ogre3D 1.7.1 vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x3A 0xA ==12515== valgrind: Unrecognised instruction at address 0x1b58182. ==12515== Your program just tried to execute an instruction that Valgrind ==12515== did not recognise. There are two possible reasons for this. ==12515== 1. Your program has a bug and erroneously jumped to a non-code ==12515== location. If you are running Memcheck and you just saw a ==12515== warning about a bad jump, it's probably your program's fault. ==12515== 2. The instruction is legitimate but Valgrind doesn't handle it, ==12515== i.e. it's Valgrind's fault. If you think this is the case or ==12515== you are not sure, please let us know and we'll try to fix it. ==12515== Either way, Valgrind will now raise a SIGILL signal which will ==12515== probably kill your program. ==12515== ==12515== Process terminating with default action of signal 4 (SIGILL) ==12515== Illegal opcode at address 0x1B58182 ==12515== at 0x1B58182: ceilf$fenv_access_off (in /usr/lib/libSystem.B.dylib) ==12515== by 0x315A886: _HIMenuGetMenuBarHeight (in /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox) ==12515== by 0x23F73DF: _NSMenuBarHeight (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==12515== by 0x23F7388: -[NSScreen _saveVisibleFrameAtIndex:] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==12515== by 0x23F72FB: +[NSScreen _updateSavedFrames] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==12515== by 0x23F70CB: +[NSScreen screens] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==12515== by 0x23FC137: +[NSScreen _zeroScreen] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==12515== by 0x23FF4A0: +[NSScreen mainScreen] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==12515== by 0x23F1014: -[NSWindow _initContent:styleMask:backing:defer:contentView:] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==12515== by 0x23F0EB2: -[NSWindow initWithContentRect:styleMask:backing:defer:] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==12515== by 0x4A8642: -[OgreConfigWindowDelegate init] (in /Library/Frameworks/Ogre.framework/Versions/1.7.1/Ogre) ==12515== by 0x4A7189: Ogre::ConfigDialog::initialise() (in /Library/Frameworks/Ogre.framework/Versions/1.7.1/Ogre)
My valgrind version is svn 11308. I'm running osx 10.6 as well. Please reopen this bug.
(In reply to comment #16) > It does not seem to be completely fixed. I'm getting this error in Ogre3D for > MAC OSX. Ogre3D runs only in 32 bit mode. > > valgrind svn as of 30-08-2010, ogre3D 1.7.1 > > vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x3A 0xA It might be actually pretty easy to fix. However, I need to see the bytes that follow the 0xA above, so I know exactly what the instruction is. Can you either: * disassemble /usr/lib/libSystem.B.dylib and find the instruction (could be difficult), or * (possibly easier) edit guest_x86_toIR.c, find where the "unhandled instruction bytes" message is printed, modify it to print 8 bytes instead of 4, and re-run.
I'll have a look at it tomorrow. Please consider changing guest_x86_toIR.c permanently in the svn, since other long instructions may exist or be added in the future.
I just rechecked and the problem has been fixed. I was unknowingly using the valgrind version from macports, instead of my just compiled one. (Both identify themselves as valgrind-3.6.0.SVN; perhaps the revision should be added somewhere). Sorry for the mistake.