[Bug libgcj/21115] false boolean argument passed from pre-compiled to interpreted method is true
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-19 23:35 --- I want to say this is libffi bug as other have pointed out on #gcj. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|java|libgcj http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21115
[Bug libgcj/21115] false boolean argument passed from pre-compiled to interpreted method is true
--- Additional Comments From green at redhat dot com 2005-04-20 00:50 --- valgrind indicates that this uninitialized memory read is cause the bad behaviour: green ==12019== Conditional jump or move depends on uninitialised value(s) green ==12019==at 0x1BEEB99C: _Jv_InterpMethod::run(void*, ffi_raw*) (interpret.cc:2113) green ==12019==by 0x1BEEFF5A: _Jv_InterpMethod::run_normal(ffi_cif*, void*, ffi_raw*, void*) (interpret.cc:277) green ==12019==by 0x1C2F51B9: ffi_closure_raw_SYSV (ffi.c:416) green ==12019==by 0x80489EE: Test::main(JArray*) (in /home/green/pr21115/a.out) interpet.cc:2113 is the ifeq opcode. So it seems that either libffi is buggy, or we're using it incorrectly. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |green at redhat dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-20 00:50:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21115
[Bug libgcj/21115] false boolean argument passed from pre-compiled to interpreted method is true
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-20
00:57 ---
Hmm, that would mean we are trying to jump based on the agrument:
insn_ifeq:
{
if (POPI() == 0)
TAKE_GOTO;
else
SKIP_GOTO;
}
NEXT_INSN;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21115
[Bug libgcj/21115] false boolean argument passed from pre-compiled to interpreted method is true
--- Additional Comments From tromey at gcc dot gnu dot org 2005-04-20 01:37 --- For me this fails if I compile Test.java with -O2, but not with -O0 or -O1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21115
[Bug libgcj/21115] false boolean argument passed from pre-compiled to interpreted method is true
--- Additional Comments From green at redhat dot com 2005-04-20 05:06 --- I think I see the problem here. The call in Test.java... t.test(false, "FALSE"); ...gets compiled into: mov%eax,0x8(%esp) ; movb $0x0,0x4(%esp) ; false boolean value mov%edx,(%esp); call *%ecx Notice that we're only storing a byte into the word here at 0x4(%esp). The "raw" libffi interface assumes that the call stack from the native code is exactly what we'd see on the bytecode stack. This obviously isn't the case, since, IIRC, booleans are represented as full words on the stack. And, indeed, when we get the value of the boolean argument we're doing a LOADI from memory copied from the 0x4(%esp). Three quarters of that word are complete garbage, so the value of our LOADI is unknown (and, for those of us seeing failures, non-zero). Possible fixes include: - promoting booleans to words for function calls - "fixing up" boolean args for raw calls - don't use the raw call mechanis I like the first option, but will it cause problems with CNI code? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21115
[Bug libgcj/21115] false boolean argument passed from pre-compiled to interpreted method is true
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-20 14:07 --- (In reply to comment #6) > I think I see the problem here. The call in Test.java... > >t.test(false, "FALSE"); And now the reason why it works on PPC, passing via registers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21115
[Bug libgcj/21115] false boolean argument passed from pre-compiled to interpreted method is true
--- Additional Comments From mark at gcc dot gnu dot org 2005-04-20 14:30 --- Posted a patch to implement option 2 of comment #6 - "fixing up" boolean args for raw calls http://gcc.gnu.org/ml/java-patches/2005-q2/msg00242.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21115
[Bug libgcj/21115] false boolean argument passed from pre-compiled to interpreted method is true
--- Additional Comments From aph at gcc dot gnu dot org 2005-04-20 14:38 --- This is indeed a libffi bug. Whether a boolean is promoted to a full word or not is a part of the system ABI. It's controlled in gcc by TARGET_PROMOTE_PROTOTYPES, and is part of the gcc back end. What you have discovered is that the raw FFI abi does not correspond to the SYSV/X86 abi, and te args need to be massaged. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21115
[Bug libgcj/21115] false boolean argument passed from pre-compiled to interpreted method is true
--- Additional Comments From aph at gcc dot gnu dot org 2005-04-21 13:38 --- OK, so it isn't a libffi bug. The odd thing here is that despite the fact that promotion of outgoing args is a machine dependent issue, each language front end is required to do it. This patch corresponds as closely as possible to the equivalent logic in the C++ front end. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21115
[Bug libgcj/21115] false boolean argument passed from pre-compiled to interpreted method is true
--- Additional Comments From mark at gcc dot gnu dot org 2005-04-21 16:04 --- The patch from comment #10 fixes the Test program and makes my patch to interpet.cc unnecessary. Also when recompiling libgcj with this a fully interpreter eclipse is again able to import and build the classpath project without any trouble. -- What|Removed |Added Component|java|libgcj Target Milestone|4.0.1 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21115
