From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14992 invoked by alias); 20 Apr 2005 05:06:45 -0000 Mailing-List: contact java-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-prs-owner@gcc.gnu.org Received: (qmail 14958 invoked by uid 48); 20 Apr 2005 05:06:45 -0000 Date: Wed, 20 Apr 2005 05:06:00 -0000 Message-ID: <20050420050645.14957.qmail@sourceware.org> From: "green at redhat dot com" To: java-prs@gcc.gnu.org In-Reply-To: <20050419223032.21115.mark@gcc.gnu.org> References: <20050419223032.21115.mark@gcc.gnu.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug libgcj/21115] false boolean argument passed from pre-compiled to interpreted method is true X-Bugzilla-Reason: CC X-SW-Source: 2005-q2/txt/msg00212.txt.bz2 List-Id: ------- 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