| Summary: | vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0xAE 0x4 0x24 0x49 | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Alisdair Owens <awo101> |
| Component: | vex | Assignee: | Julian Seward <jseward> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | ashutoshvsingh, dkozlowski, doodydexter, francesco.19745, james.ravn, konstantin.s.serebryany, misieck, nilesh_asher, njn, pelloux+kde, tom |
| Priority: | NOR | ||
| Version: | 3.4.1 | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Bug Depends on: | |||
| Bug Blocks: | 253451 | ||
| Attachments: |
patch proposal for fxsave handling
patch proposal for fxrstor handling |
||
|
Description
Alisdair Owens
2009-05-28 11:37:38 UTC
That is an FXSAVE instruction with the REX.W prefix bit set which we don't seem to handle at the moment - we do handle normal FXSAVE instructions.
There is a comment in the instruction decoder which says:
/* 0F AE /0 = FXSAVE m512 -- write x87 and SSE state to memory.
Note that REX.W 0F AE /0 writes a slightly different format and
we don't handle that here. */
What it doesn't say is that we don't handle it anywhere else either ;-)
I confirm this issue. I run valgrind-3.4.1, and often get vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0xAE 0x4 0x24 0x49 when running a more complicated java program (with jni). Running x86_64 with fedora 11 on a Core2Duo laptop. Has this been resolved in later versions? Should I upgrade? Still happens on SVN r11051. To reproduce run firefox under valgrind and visit this page with an applet: "http://java.com/en/download/help/testvm.xml". Or run jEdit. vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0xAE 0x4 0x24 0x49 ==14235== valgrind: Unrecognised instruction at address 0x22eb6c46. As of svn11120 this still is an issue. I am attempting to add in the bits to VEX/priv/guest_amd64_toIR.c to get it to work , but I can not find any documentation on the internals of Valgrind and how it handles IR Decodes. Any place you could point me to do this would be most helpful *** Bug 241951 has been marked as a duplicate of this bug. *** Hi,
Is there a workaround?
Ashutosh
=======================================
Ashutosh Singh
=======================================
> From: tom@compton.nu
> To: ashutoshvsingh@hotmail.com
> Subject: [Bug 194402] vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0xAE 0x4 0x24 0x49
> Date: Thu, 17 Jun 2010 09:43:16 +0200
>
> https://bugs.kde.org/show_bug.cgi?id=194402
>
>
> Tom Hughes <tom@compton.nu> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> CC| |ashutoshvsingh@hotmail.com
>
>
>
>
> --- Comment #5 from Tom Hughes <tom compton nu> 2010-06-17 09:42:42 ---
> *** Bug 241951 has been marked as a duplicate of this bug. ***
>
> --
> Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
(In reply to comment #4) > As of svn11120 this still is an issue. I am attempting to add in the bits to > VEX/priv/guest_amd64_toIR.c to get it to work , but I can not find any > documentation on the internals of Valgrind and how it handles IR Decodes. Any > place you could point me to do this would be most helpful Basically what you need to do is make a copy of the existing FXSAVE handling, and modify it. I think the check to identify the insn should be if (haveNo66noF2noF3(pfx) && sz == 8 && insn[0] == 0x0F && insn[1] == 0xAE && !epartIsReg(insn[2]) && gregOfRexRM(pfx,insn[2]) == 0) { This differs from the existing version in the "sz == 8" part, and guarantees that it will only match if a REX.W prefix has been seen. Then, you will need to make a corresponding clone of amd64g_dirtyhelper_FXSAVE which does the actual dirty work of producing the in-memory image. One hint is to write a good test program first. A good test program will tell you if your implementation is correct, and generally makes the problem much more stress-free. Again, the tree contains a test program memcheck/tests/amd64/fxsave-amd64.c for the existing FXSAVE implementation, so you could start by modifying that. The usual way these test programs work is that they must print exactly the same result when running natively and on Valgrind, and the above one is no exception. If someone wants to come up with a patch I'll be happy to give feedback on it. Created attachment 49737 [details]
patch proposal for fxsave handling
Hi, i'm far from being an expert but I'd like to hear your opinion on a simple modification to correct this bug. According to this : http://support.amd.com/us/Embedded_TechDocs/24593.pdf (p. 300) the only difference in 64-bit mode between FXSAVE and FXSAVE + REX.W bit set is that RIP and RDP are stored in a 'sel:offset' format when using 32bit operands. When looking at amd64g_dirtyhelper_FXSAVE, both of these are actually always set to '0' (l. 1545). So maybe one could simply change the test in guest_amd64_toIR to match both versions (and removing the 2 relevant asserts). I have tested this modification on a simple program (copy-paste from fxsave64-amd64.c and using "rex64/fxsave" instead of "fxsave" ) and it seems ok. What do you think ? (I've added a very simple patch which contains these modifcations) Can anyone confirm that this patch gets rid of the JRE crash? Patch looks good, but I'd like some confirmation first that it solves the original problem. (In reply to comment #10) > Can anyone confirm that this patch gets rid of the JRE crash? ping! I'd like to commit this _if_ someone can confirm it fixes the JRE crash. Hi,I do not have the setup anymore to verify it.Ashutosh
=======================================
Ashutosh Singh
=======================================
> From: jseward@acm.org
> To: ashutoshvsingh@hotmail.com
> Subject: [Bug 194402] vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0xAE 0x4 0x24 0x49
> Date: Tue, 28 Sep 2010 18:30:08 +0200
>
> https://bugs.kde.org/show_bug.cgi?id=194402
>
>
>
>
>
> --- Comment #11 from Julian Seward <jseward acm org> 2010-09-28 18:29:48 ---
> (In reply to comment #10)
> > Can anyone confirm that this patch gets rid of the JRE crash?
>
> ping! I'd like to commit this _if_ someone can confirm it fixes
> the JRE crash.
>
> --
> Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
I'm going to push this till after 3.6.0 unless anyone can confirm that this fixes the JRE problem. My two cents: 1) I can reproduce the bug (unfortunately on a very large app only) 2) The proposed fix does *NOT* eliminate the problem: with the fix I can see the following assert: vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0xAE 0xC 0x24 0x48 Note the last byte (was: 0x49) Do you plan to fix this as well? Thanks! Here's an additional patch : it tries to implement the missing FXRSTOR feature for amd64 guests. Again, it's almost a copy-paste from the x86 code with a few minor modifications. It should address your issue (if I'm correct, the fourth byte going from 0x4 to 0xC means 'FXRSTOR' instead of 'FXSAVE'). Let us know if it works. Created attachment 54029 [details]
patch proposal for fxrstor handling
Yes! With these two patches my program passes the point where it failed previously. I found this bug because I'm having the identical issue - running 64-bit JVM in valgrind. I applied the patches to the 3.6.0 source (my company firewall blocks svn access) and tried running it. Now the process simply hangs with no information. Fixed, vex r2084. FXSAVE and FXRSTOR, both REX.W and non-REX.W variants, are now supported. Thanks all for the various patches and how-to-fix suggestions. *** Bug 143323 has been marked as a duplicate of this bug. *** *** Bug 149838 has been marked as a duplicate of this bug. *** |