public inbox for java-prs@sourceware.org
help / color / mirror / Atom feed
From: "green at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: java-prs@gcc.gnu.org
Subject: [Bug libgcj/21115] false boolean argument passed from pre-compiled to interpreted method is true
Date: Wed, 20 Apr 2005 05:06:00 -0000	[thread overview]
Message-ID: <20050420050645.14957.qmail@sourceware.org> (raw)
In-Reply-To: <20050419223032.21115.mark@gcc.gnu.org>


------- 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


  parent reply	other threads:[~2005-04-20  5:06 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-19 22:30 [Bug java/21115] New: " mark at gcc dot gnu dot org
2005-04-19 22:55 ` [Bug java/21115] " daney at gcc dot gnu dot org
2005-04-19 23:35 ` [Bug libgcj/21115] " pinskia at gcc dot gnu dot org
2005-04-20  0:50 ` green at redhat dot com
2005-04-20  0:57 ` pinskia at gcc dot gnu dot org
2005-04-20  1:37 ` tromey at gcc dot gnu dot org
2005-04-20  5:06 ` green at redhat dot com [this message]
2005-04-20 14:07 ` pinskia at gcc dot gnu dot org
2005-04-20 14:30 ` mark at gcc dot gnu dot org
2005-04-20 14:38 ` aph at gcc dot gnu dot org
2005-04-21 13:38 ` aph at gcc dot gnu dot org
2005-04-21 15:02 ` [Bug java/21115] " aph at gcc dot gnu dot org
2005-04-21 16:04 ` [Bug libgcj/21115] " mark at gcc dot gnu dot org
2005-04-21 16:06 ` [Bug java/21115] " pinskia at gcc dot gnu dot org
2005-04-21 16:23 ` cvs-commit at gcc dot gnu dot org
2005-04-28 16:35 ` cvs-commit at gcc dot gnu dot org
2005-04-29 18:43 ` cvs-commit at gcc dot gnu dot org
2005-04-29 18:44 ` cvs-commit at gcc dot gnu dot org
2005-04-29 19:24 ` pinskia at gcc dot gnu dot org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050420050645.14957.qmail@sourceware.org \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=java-prs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).