|
From: JVZ <je...@fo...> - 2012-06-20 20:49:57
|
Running a piece of code which called powl() from the math function, valgrind exits with message like the following: vex and64->IR: unhandled instruction bytes: 0xDA 0xE9 0xDF 0xE0 valgrind: Unrecognized instruction at address: 0x3411235BF4. <blabla> Illegal opcode at address 0x3411235BF4: at 0x3411235BF4: __ieee754_powl (in /lib64/libm-2.5.so) ........ I checked and this turns out to be a fragment in the __ieee754_powl() routine executing these two instructions: fucompp fnstsw This fragment appears also unchanged in later versions of the glibc math library, for x86-64 architecture. I checked Bugzilla, it doesn't seem listed in the bugs database already. Hopefully, this is something that can be fixed in next version of valgrind... -- JVZ |
|
From: Philippe W. <phi...@sk...> - 2012-06-20 21:00:27
|
On Wed, 2012-06-20 at 15:23 -0500, JVZ wrote: > I checked Bugzilla, it doesn't seem listed in the bugs database already. > > > Hopefully, this is something that can be fixed in next version of valgrind... It would be worth trying the latest 3.8.0 SVN version and see if it still fails. And if it still fails, to enter a bug in the bug database. Philippe |
|
From: John R. <jr...@bi...> - 2012-06-20 21:28:09
|
> vex and64->IR: unhandled instruction bytes: 0xDA 0xE9 0xDF 0xE0 > I checked and this turns out to be a fragment in the __ieee754_powl() routine > executing these two instructions: > > fucompp > fnstsw > I checked Bugzilla, it doesn't seem listed in the bugs database already. Thank you for checking. Now you need to follow through, by performing the next step: > Hopefully, this is something that can be fixed in next version of valgrind... It is unlikely to be fixed unless you file a bug report. Visit http://valgrind.org/ and click on the Bug Reports link in the left column. -- |
|
From: JVZ <je...@fo...> - 2012-06-20 21:31:50
|
On Wed, 20 Jun 2012 23:00:20 +0200 Philippe Waroquiers <phi...@sk...> wrote: > On Wed, 2012-06-20 at 15:23 -0500, JVZ wrote: > > I checked Bugzilla, it doesn't seem listed in the bugs database already. > > > > > > Hopefully, this is something that can be fixed in next version of valgrind... > It would be worth trying the latest 3.8.0 SVN version and see if > it still fails. > And if it still fails, to enter a bug in the bug database. Yes, I plan to test the svn version of valgrind tomorrow. Have there been additions to the supported instruction set in valgrind since version 3.7.0? Curiously, transcendental math functions still use old x87 regs, even when on 64 bit. Here I thought those x87 registers were "legacy" in x86-64... - JVZ +----------------------------------------------------------------------------+ | Copyright (C) 16:20 06/20/2012 Jeroen van der Zijp. All Rights Reserved. | +----------------------------------------------------------------------------+ |
|
From: Philippe W. <phi...@sk...> - 2012-06-20 22:20:05
|
On Wed, 2012-06-20 at 16:31 -0500, JVZ wrote: > Yes, I plan to test the svn version of valgrind tomorrow. Have there been > additions to the supported instruction set in valgrind since version 3.7.0? I do not know the details, but yes, I have seen many new instructions being implemented. No idea if what you need is there. Testing with 3.8.0 SVN will be the easiest way to check. Philippe |
|
From: John R. <jr...@bi...> - 2012-06-21 03:55:22
|
> vex and64->IR: unhandled instruction bytes: 0xDA 0xE9 0xDF 0xE0
> valgrind: Unrecognized instruction at address: 0x3411235BF4.
> Illegal opcode at address 0x3411235BF4:
> at 0x3411235BF4: __ieee754_powl (in /lib64/libm-2.5.so)
> I checked and this turns out to be a fragment in the __ieee754_powl() routine
> executing these two instructions:
Can you write a 10-line test case and submit that in a bug report?
There is evidence that at least some instances of fucompp and fnstsw
already work.
> fucompp
According to NEWS, FUCOMPP appeared in valgrind-3.3.1 (4 June 2008)
and is bug 161378 among others.
Source files VEX/priv/guest_amd64_toIR.c and VEX/priv/guest_x86_toIR.c
both have:
case 0xE9: /* FUCOMPP %st(0),%st(1) */
DIP("fucompp %%st(0),%%st(1)\n");
/* This forces C1 to zero, which isn't right. */
put_C3210(
binop( Iop_And32,
binop(Iop_Shl32,
binop(Iop_CmpF64, get_ST(0), get_ST(1)),
mkU8(8)),
mkU32(0x4500)
));
fp_pop();
fp_pop();
break;
> fnstsw
Again according to NEWWS, FNSTSW appeared in valgrind-3.1.1 (15 March 2006)
and is bug 117366 among others.
Source files VEX/priv/guest_amd64_toIR.c and VEX/priv/guest_x86_toIR.c
both have:
case 7: { /* FNSTSW m16 */
IRExpr* sw = get_FPU_sw();
vassert(typeOfIRExpr(irsb->tyenv, sw) == Ity_I16);
storeLE( mkexpr(addr), sw );
DIP("fnstsw %s\n", dis_buf);
break;
}
--
|