|
From: Eliot M. <mo...@cs...> - 2012-05-21 17:16:49
|
Dear developers -- I have a program (IBM's Java) that seems to use FCOMP, yet that instruction is commented out in guest_amd64-toIR.c. Can anyone offer insight as to why? (Yet another instruction it seems that I need to add to get JVMs to work under valgrind ...) Regards -- Eliot Moss |
|
From: John R. <jr...@bi...> - 2012-05-21 17:50:19
|
> Dear developers -- I have a program (IBM's Java)
> that seems to use FCOMP, yet that instruction is
> commented out in guest_amd64-toIR.c. Can anyone
> offer insight as to why? (Yet another instruction
> it seems that I need to add to get JVMs to work
> under valgrind ...)
The probable cause is the comment:
//.. /* This forces C1 to zero, which isn't right. */
Note that there are 8 instances of FCOMP (namely, {single,double}*
{register,memory}*{x86,amd64}) yet only one of those instances is
commented out, despite the multiple comments about C1 being bad:
----- guest_amd64-toIR.c
//.. case 3: /* FCOMP single-real */
case 0xD8 ... 0xDF: /* FCOMP %st(?),%st(0) */
case 3: /* FCOMP double-real */
case 0xD9: /* FCOMPP %st(0),%st(1) */
-----
----- guest_t_x86_toIR.c
case 3: /* FCOMP single-real */
case 0xD8 ... 0xDF: /* FCOMP %st(?),%st(0) */
case 3: /* FCOMP double-real */
case 0xD9: /* FCOMPP %st(0),%st(1) */
-----
--
|
|
From: Julian S. <js...@ac...> - 2012-05-21 20:42:42
|
On Monday, May 21, 2012, Eliot Moss wrote: > Dear developers -- I have a program (IBM's Java) > that seems to use FCOMP, yet that instruction is > commented out in guest_amd64-toIR.c. Can anyone > offer insight as to why? (Yet another instruction > it seems that I need to add to get JVMs to work > under valgrind ...) The reason you are seeing this phenomenon (viz, apparently perfectly reasonable instructions are not supported) is because what often happens is that we tend to implement insns on demand. In practice that means that the set of implemented instructions is driven by whatever "dialect" gcc and/or GNU as emit. When you bring along a new compiler (this JVM) and it ventures outside that dialect, things break. iow, this FCOMP variant is not implemented because gcc has never generated it, and no other compiler (till now) has "demanded it". Should be pretty simple to do, basically uncomment the relevant clause (which is from the x86 front end) and wrap the missing unop(Iop_32Uto64, ...) function application around it. Then send the patch this way .. J |