Bug 296577

Summary:	vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x3A 0x17 (extractps)
Product:	[Developer tools] valgrind	Reporter:	jojo-bln <jojo47de>
Component:	vex	Assignee:	Rhys Kidd <rhyskidd>
Status:	RESOLVED INTENTIONAL
Severity:	normal	CC:	handrei, rhyskidd, tom
Priority:	NOR
Version:	3.7 SVN
Target Milestone:	---
Platform:	macOS (DMG)
OS:	macOS
See Also:	https://bugs.kde.org/show_bug.cgi?id=254616 https://bugs.kde.org/show_bug.cgi?id=332917
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	Valgrind run log for an OpenGL OSX application crash compiled on x86 instead of amd64

Description jojo-bln 2012-03-22 20:07:16 UTC

Hi, I am new here .. have downloaded SVN valgrind and hoped that above message does
not appear anymore. Found related Bugfix : 558870, but obiviously for amd64. But I have
Intel. Happens in OpenGL graphics (gleSetVPTransformFuncAll). On Linux/Ubuntu running "memcheck" exactly same code works fine. Can be my fault too, but I have checked twice.
My code is complex and I really like the valgrind stuff (memcheck,helgrind,cachegrind) which
I used extensively during the last 2 years. (MAC OS X 10.6.8)

Comment 1 Andrei Hanganu 2012-03-27 09:08:01 UTC

Created attachment 69929 [details]
Valgrind run log for an OpenGL OSX application crash compiled on x86 instead of amd64

I have the same issue described above.
Crash in on this action:
vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x3A 0xDF

See attachment for full log.
The app is a sample OpenGL program from Apple's developer section.
On OSX 10.7.3, application compiled with XCode Version 4.3.2 (4E2002)

Comment 2 Andrei Hanganu 2012-03-27 09:09:18 UTC

The issue takes place on the 3.8.0-SVN version of Valgrind, checked out 10 minutes ago.

$ valgrind --version
valgrind-3.8.0.SVN
$

Comment 3 jojo-bln 2012-03-27 11:18:22 UTC

Hi Andrei,
I just want let you know, that I received your Mail.
Sounds that the OpenGL Problem is on snow Leopard as well as on Lion.
Maybe this is related to Intel Platform only, but no AMD.
Can I do something ?
Best regards,
Georg



________________________________
 Von: Andrei Hanganu <handrei@gmail.com>
An: jojo47de@yahoo.de 
Gesendet: 11:08 Dienstag, 27.März 2012
Betreff: [Bug 296577] vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x3A 0x17
 
https://bugs.kde.org/show_bug.cgi?id=296577

--- Comment #1 from Andrei Hanganu <handrei@gmail.com> ---
Created attachment 69929 [details]
  --> https://bugs.kde.org/attachment.cgi?id=69929&action=edit
Valgrind run log for an OpenGL OSX application crash compiled on x86 instead of
amd64

I have the same issue described above.
Crash in on this action:
vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x3A 0xDF

See attachment for full log.
The app is a sample OpenGL program from Apple's developer section.
On OSX 10.7.3, application compiled with XCode Version 4.3.2 (4E2002)

Comment 4 Julian Seward 2012-03-27 17:12:23 UTC

This is AESKEYGENASSIST, which is supported in 64 bit mode
but not 32 bit.  Realistically I don't think it will get supported in
32 bit mode -- that doesn't support anything after SSSE3.  Can you
develop in 64 bit mode instead?  The main support emphasis now
is x86_64 (64 bit) and ARM; x86 (32 bit) is more-or-less "legacy".

Comment 5 Andrei Hanganu 2012-03-28 06:44:21 UTC

It seems XCode is to blame here, inserting x64 instructions in what is supposed to be x86. The apps we are developing are games intended for iOS which we need to keep to x86 for network structures compatibility and resources loading. Everything is based on x86 data sizes.
Unfortunately a cocoa-free OpenGL program failed to link properly but there's always Linux :)

Thanks for the feedback.

Comment 6 jojo-bln 2012-03-29 09:41:49 UTC

Thank you for your reply and spending your time to this issue.

I Google'd arnoud the AESKEYGENASSIST. It's definitely not new to
your valgrind group. I find lots of related questions/problems.
OK, I have Linux 32/64 bit where all is fine. But my point is to
compare the ("overestimated") advantages of 32 bit vs. 64 bit.
If I can not run for example cachegrind on MAC OS combined with 
OpenGL, I can not get the information, I would like to see. And as
far as I understand, only because of the funny Intel encryption
AES instructions. I furthermore have the remark that Apple's oper-  
iating systems and OpenGL are mainstream. 

Please let my ask for a workaround : Is it possible to put a few lines
in "priv/guest_x86_helpers.c" to skip all instructions that look
like : 0X66 0XF 0X3A 0X?? 
This would be a big step forward. Thank you.




________________________________
 Von: Julian Seward <jseward@acm.org>
An: jojo47de@yahoo.de 
Gesendet: 19:12 Dienstag, 27.März 2012
Betreff: [Bug 296577] vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x3A 0x17
 
https://bugs.kde.org/show_bug.cgi?id=296577

--- Comment #4 from Julian Seward <jseward@acm.org> ---
This is AESKEYGENASSIST, which is supported in 64 bit mode
but not 32 bit.  Realistically I don't think it will get supported in
32 bit mode -- that doesn't support anything after SSSE3.  Can you
develop in 64 bit mode instead?  The main support emphasis now
is x86_64 (64 bit) and ARM; x86 (32 bit) is more-or-less "legacy".

Comment 7 Tom Hughes 2014-02-03 12:56:29 UTC

Not sure why Julian diagnosed this as AESKEYGENASSIST as it actually appears to be EXTRACTPS but the conclusion is the same - we currently only support that in 64 bit mode.

Comment 8 Rhys Kidd 2015-03-07 09:01:23 UTC

Should we consider closing and WONTFIX? 
Original report was also using what is now a very old Xcode and compiler.

Comment 9 Rhys Kidd 2015-05-31 23:38:40 UTC

extractps is an SSE4.1 instruction.
SSE4 isn't supported in 32 bit mode, only 64 bit mode.  32 bit mode supports only up to and including SSSE3.
http://www.valgrind.org/docs/manual/manual-core.html#manual-core.limits

There are no current plans to support SSE4 on 32-bit.  Please use 64-bit.