Summary: | vex amd64->IR: unhandled instruction bytes: 0xC5 0xF9 0x57 0xC0 0xC5 0xFB 0x10 0xD | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | Sascha Jopen <jopen> |
Component: | vex | Assignee: | Julian Seward <jseward> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | b.brachaczek, Enrico_m, tom |
Priority: | NOR | ||
Version: | 3.7 SVN | ||
Target Milestone: | --- | ||
Platform: | Gentoo Packages | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Sascha Jopen
2011-08-26 13:41:33 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... 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. 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? 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. (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. Thanks for the fast replies. Compiling libxml2 without optimizations indeed "fixes" the problem, at least for now. (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 *** |