Bug 280835 - vex amd64->IR: unhandled instruction bytes: 0xC5 0xF9 0x57 0xC0 0xC5 0xFB 0x10 0xD
Summary: vex amd64->IR: unhandled instruction bytes: 0xC5 0xF9 0x57 0xC0 0xC5 0xFB 0x1...
Status: RESOLVED DUPLICATE of bug 273475
Alias: None
Product: valgrind
Classification: Developer tools
Component: vex (show other bugs)
Version: 3.7 SVN
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-26 13:41 UTC by Sascha Jopen
Modified: 2011-10-13 08:49 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sascha Jopen 2011-08-26 13:41:33 UTC
Version:           3.7 SVN (using KDE 4.7.0) 
OS:                Linux

This illegal opcode appears when calling xmlXPathInit() from within an application. Both libxml2-2.7.8 and my application are compiled and run on Intel Core i3-2310M CPU. Even when building a program, which only contains this single call, the problem arises. I was not able to narrow down the exact call within xmlXPathInit, which causes the problem, nor do i know which instruction these opcode refers to.

Valgrind SVN revision 12003.


Reproducible: Always

Steps to Reproduce:
Compile and link a program against libxml2, which calls xmlXPathInit()
Run this program with under valgrind.

Actual Results:  
==17277== Memcheck, a memory error detector
==17277== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==17277== Using Valgrind-3.7.0.SVN and LibVEX; rerun with -h for copyright info
==17277== Command: /home/jopen/test
==17277== 
vex amd64->IR: unhandled instruction bytes: 0xC5 0xF9 0x57 0xC0 0xC5 0xFB 0x10 0xD
==17277== valgrind: Unrecognised instruction at address 0x3f4e282890.
==17277==    at 0x3F4E282890: xmlXPathInit (in /usr/lib64/libxml2.so.2.7.8)
==17277==    by 0x400697: main (in /home/jopen/test)
==17277== Your program just tried to execute an instruction that Valgrind
==17277== did not recognise.  There are two possible reasons for this.
==17277== 1. Your program has a bug and erroneously jumped to a non-code
==17277==    location.  If you are running Memcheck and you just saw a
==17277==    warning about a bad jump, it's probably your program's fault.
==17277== 2. The instruction is legitimate but Valgrind doesn't handle it,
==17277==    i.e. it's Valgrind's fault.  If you think this is the case or
==17277==    you are not sure, please let us know and we'll try to fix it.
==17277== Either way, Valgrind will now raise a SIGILL signal which will
==17277== probably kill your program.
==17277== 
==17277== Process terminating with default action of signal 4 (SIGILL)
==17277==  Illegal opcode at address 0x3F4E282890
==17277==    at 0x3F4E282890: xmlXPathInit (in /usr/lib64/libxml2.so.2.7.8)
==17277==    by 0x400697: main (in /home/jopen/test)
==17277== 
==17277== HEAP SUMMARY:
==17277==     in use at exit: 0 bytes in 0 blocks
==17277==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==17277== 
==17277== All heap blocks were freed -- no leaks are possible
==17277== 
==17277== For counts of detected and suppressed errors, rerun with: -v
==17277== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)

Expected Results:  
Valgrind should recognize the used instructions.
Comment 1 Tom Hughes 2011-08-26 14:42:57 UTC
Can you post a disassembly of that function? Only if I'm reading the Intel manuals correctly then OxC5 is not valid in 64 bit mode...
Comment 2 Tom Hughes 2011-08-26 14:58:35 UTC
So I've updated my manuals now and apparently "0xC5 0xF9" is a VEX prefix which is some new piece of insanity, because x86 instruction decoding just wasn't complicated enough...

That leaves 0x57 as the real instruction, with an 0x0F prefix implied by the 2 byte VEX prefix.

At the end of which we have 0x0F 0x57 otherwise known as xorps which is an instruction we do understand so it looks like the issue is that we don't know how to handle these new VEX prefixes.
Comment 3 Sascha Jopen 2011-08-26 15:50:14 UTC
I'm not sure, why x86 instructions are involved, because both my application, as well as libxml2 were compiled and run on a 64-bit OS. Shouldn't the processor run in 64-bit native mode or compatibility mode?

Anyway, if you need further information, feel free to give me instructions, what to do. Regarding the disassembly, is this still necessary? If so, can you please tell me, what i have to do and which tools to use?
Comment 4 Tom Hughes 2011-08-26 15:54:04 UTC
Sorry, I was using x86 as shorthand for the whole family including both 32 and 64 bit instructions.

I think we know what the problem is, but I'm guessing it's not going to be solved very quickly as adding logic to decode and handle VEX prefixes looks like it will be rather non-trivial.

For the time being you probably need to tone down your optimisation settings to something valgrind can cope with. Compiling for the full range of instructions on a recent processor is always likely to lead to problems I'm afraid.
Comment 5 Julian Seward 2011-08-26 16:28:49 UTC
(In reply to comment #2)
> So I've updated my manuals now and apparently "0xC5 0xF9" is a VEX prefix which
> is some new piece of insanity, because x86 instruction decoding just wasn't
> complicated enough...

Yeah, it basically means it's an AVX insn.  Doing AVX is going to be a
whole trip since it largely duplicates SSE2 but makes it 256 bits wide
instead.  It will get fixed, but not in the next few weeks.
Comment 6 Sascha Jopen 2011-08-26 18:51:37 UTC
Thanks for the fast replies. Compiling libxml2 without optimizations indeed "fixes" the problem, at least for now.
Comment 7 Julian Seward 2011-10-13 08:49:11 UTC
(In reply to comment #2)
> So I've updated my manuals now and apparently "0xC5 0xF9" is a VEX prefix which
> is some new piece of insanity, because x86 instruction decoding just wasn't
> complicated enough...

Yeah, it elevates it into the surreal.  It's kind of like having your
instruction set encoding designed by Salvador Dali.

Anyway, closing this as a dup of the canonical AVX tracking bug
(bug 273475).

*** This bug has been marked as a duplicate of bug 273475 ***