This is the mail archive of the gcc-prs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

java/1347: Bytecode parser fails on 64-bit systems



>Number:         1347
>Category:       java
>Synopsis:       Bytecode parser fails on 64-bit systems
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    apbianco
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Dec 20 12:19:16 PST 2000
>Closed-Date:    Tue Aug 29 09:15:02 PDT 2000
>Last-Modified:  Tue Sep  5 18:16:00 PDT 2000
>Originator:     Jeff Sturm
>Release:        current CVS
>Organization:
>Environment:
alpha-unknown-linux-gnu
>Description:
The bytecode parser doesn't read negative indices correctly
in e.g. tableswitch instructions.  It will fail to
compile or dump bytecode with a tableswitch instruction
at a range starting below zero.
>How-To-Repeat:
On a 64-bit machine (alpha, ia64, sparc64) do:

gcj -C Foo.java
jcf-dump Foo.class

You should see something like:
Method name:"foo" public Signature: 6=(int)int
Attribute "Code", length:64, max_stack:3, max_locals:2, code_length:32
  0: iload_1
  1: tableswitch low=-4294967297, high=1, default=30
-4294967297: 28
-4294967296: 28
-4294967295: 28
Bad byte codes.

>Fix:
Fix WORD_TO_INT to properly sign extend negative numbers on
64-bit architectures.  The obvious fix (redefining int32 in
javaop.h to a 32-bit type) fails, so I'm stumped :(
>Release-Note:

>Audit-Trail:

Formerly PR gcj/321


From: Anthony Green <green@cygnus.com>
To: "'java-gnats@sourceware.cygnus.com'"
	 <java-gnats@sourceware.cygnus.com>,
        "'apbianco@cygnus.com'"
	 <apbianco@cygnus.com>,
        "'jsturm@detroit.appnet.com'"
	 <jsturm@detroit.appnet.com>
Cc:  
Subject: re: gcj/321
Date: Wed, 16 Aug 2000 15:59:57 -0700

 I noticed the same thing the other day on IA-64.  The test_long.java test 
 case fails because int32 is actually 64-bits on 64-bit hosts.
 
 http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%26pr=321%26database  
 =java

From: Jeff Sturm <jsturm@detroit.appnet.com>
To: java-gnats@sourceware.cygnus.com, apbianco@cygnus.com
Cc: aph@cygnus.com
Subject: Re: gcj/321
Date: Fri, 18 Aug 2000 17:46:24 -0400

 I looked closer at this.  The
 
 #define int32 long
 
 is necessary, though it looks wrong, because tree pointers are stored in jword
 types (ick).  Consequently the WORD_TO_INT macro is wrong:
 
 /* Sign extend w. */
 static inline jint
 WORD_TO_INT(jword w)
 {
   jint n = w;
   n ^= (jint)1 << 31;
   n -= (jint)1 << 31;
   return n;
 }
 
 I don't really understand the bit arithmetic used there, though it is clearly
 intended for 32-bit types.  Anyway, the comment is probably wrong... there's no
 real "sign extend" taking place since jword and jint are always both the same
 size as an int32.  A simple cast ought to work, and indeed works for me.
 
 (I'm Cc:'ing Andrew since he originally committed the WORD_TO_INT function.)
 
 
 http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view&pr=321&database=java
 
 --
 Jeff Sturm
 jeff.sturm@appnet.com

From: Jeff Sturm <jsturm@detroit.appnet.com>
To: java-gnats@sourceware.cygnus.com
Cc:  
Subject: Re: gcj/321
Date: Sat, 19 Aug 2000 13:16:01 -0400

 (This is a resend after my original mail bounced... is java-prs a read-only
 list?)
 
 Anthony Green wrote:
 > Did you try test_long.java?   What was your patch, exactly?
 
 Yes, test_long.java works for me when compiled from either source or bytecode.
 
 This isn't a "patch" really, more like a quick hack... the gcj code as it is
 still isn't portable, and probably won't be easy to fix.
 
 In short, since jword and jint must be the same size, the xor and sub statements
 negate each other, and WORD_TO_INT becomes nothing but a cast:
 
 Index: javaop.h
 ===================================================================
 RCS file: /cvs/gcc/egcs/gcc/java/javaop.h,v
 retrieving revision 1.8
 diff -u -p -r1.8 javaop.h
 --- javaop.h    2000/05/03 18:09:27     1.8
 +++ javaop.h    2000/08/19 15:53:35
 @@ -113,10 +113,7 @@ WORD_TO_FLOAT(jword w)
  static inline jint
  WORD_TO_INT(jword w)
  {
 -  jint n = w;
 -  n ^= (jint)1 << 31;
 -  n -= (jint)1 << 31;
 -  return n;
 +  return (jint)w;
  } 
  
  static inline jlong

From: Jeff Sturm <jsturm@detroit.appnet.com>
To: java-gnats@sourceware.cygnus.com, apbianco@cygnus.com
Cc:  
Subject: Re: gcj/321
Date: Fri, 25 Aug 2000 10:11:23 -0400

 Andrew posted a patch that should clear up any WORD_TO_INT problems:
 
 http://gcc.gnu.org/ml/gcc-patches/2000-08/msg00897.html
 
 Alex, can you close this PR?
 
 http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view&pr=321&database=java
 
 --
 Jeff Sturm
 jeff.sturm@appnet.com

From: Alexandre Petit-Bianco <apbianco@cygnus.com>
To: jeff.sturm@appnet.com, bryce@albatross.co.nz
Cc: java-gnats@sourceware.cygnus.com
Subject: Re: gcj/321
Date: Fri, 25 Aug 2000 08:58:28 -0700 (PDT)

 Jeff Sturm writes:
 > Andrew posted a patch that should clear up any WORD_TO_INT problems:
 > 
 > http://gcc.gnu.org/ml/gcc-patches/2000-08/msg00897.html
 
 Yes. I was also going to give this patch a bit of review and formal
 testing before approving it (though I'm pretty sure it's fine.)
 
 > Alex, can you close this PR?
 
 I will. Oh, by the way, have you seen:
 
   http://gcc.gnu.org/ml/gcc-patches/2000-08/msg00907.html
 
 It's the long awaited patch to 252, 214 and 160. Can you please
 confirm that it fixes the two PRs you submitted (252 and 214. 214 was
 on Alpha hardware.) I'd like Bryce to also confirm that it fixes 160.
 
 If testing goes well, I should be able to check these two patches in
 and close 321, 252, 214 and 160. Yeah!
 
 ./A
 
 
 
 
 
 

From: Jeff Sturm <jsturm@detroit.appnet.com>
To: apbianco@redhat.com
Cc: bryce@albatross.co.nz, java-gnats@sourceware.cygnus.com
Subject: Re: gcj/321
Date: Fri, 25 Aug 2000 14:00:07 -0400

 Alexandre Petit-Bianco wrote:
 > Jeff Sturm writes:
 > > Andrew posted a patch that should clear up any WORD_TO_INT problems:
 > >
 > > http://gcc.gnu.org/ml/gcc-patches/2000-08/msg00897.html
 > 
 > Yes. I was also going to give this patch a bit of review and formal
 > testing before approving it (though I'm pretty sure it's fine.)
 
 Oh, that's OK... I meant to say "... if you approve the patch" but hit Send a
 little too quick :\
 
 My proposed fix (which you didn't see) typedef'ed jint as an `int' guaranteeing
 it would be 32 bits on most (all?) platforms that can host GCC.  Andrew left
 jint alone, instead fixing WORD_TO_INT to be more tolerant of various integer
 widths.
 
 I don't have a strong opinion either way, except that "typedef long int32" is
 nonintuitive to say the least... but Andrew's patch indeed fixes gcj/321 on
 Alpha (didn't try it on IA32).  Also there are too many pointer<->int
 conversions in gcj for my comfort.
 
 > > Alex, can you close this PR?
 > 
 > I will. Oh, by the way, have you seen:
 > 
 >   http://gcc.gnu.org/ml/gcc-patches/2000-08/msg00907.html
 
 Yes.  I haven't looked closely at it... will try it when I get a chance. 
 Thanks.
 
 --
 Jeff Sturm
 jeff.sturm@appnet.com
State-Changed-From-To: open->closed
State-Changed-By: apbianco
State-Changed-When: Tue Aug 29 09:15:02 2000
State-Changed-Why:
    I just checked in Andrew Haley's patch:
    
      http://gcc.gnu.org/ml/gcc-patches/2000-08/msg00897.html

From: apbianco@cygnus.com
To: apbianco@cygnus.com, java-gnats@sourceware.cygnus.com,
  jsturm@detroit.appnet.com
Cc:  
Subject: Re: gcj/321
Date: 29 Aug 2000 16:15:02 -0000

 Synopsis: Bytecode parser fails on 64-bit systems
 
 State-Changed-From-To: open->closed
 State-Changed-By: apbianco
 State-Changed-When: Tue Aug 29 09:15:02 2000
 State-Changed-Why:
     I just checked in Andrew Haley's patch:
     
       http://gcc.gnu.org/ml/gcc-patches/2000-08/msg00897.html
 
 http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view&pr=321&database=java

From: Alexandre Petit-Bianco <apbianco@cygnus.com>
To: jeff.sturm@appnet.com
Cc: bryce@albatross.co.nz, aph@cygnus.com, java-gnats@sourceware.cygnus.com
Subject: Re: gcj/321
Date: Tue, 29 Aug 2000 14:44:11 -0700 (PDT)

 [I forgot a comma on the CC line.]
 
 Jeff Sturm writes:
 
 > > > Alex, can you close this PR?
 > > 
 > > I will. Oh, by the way, have you seen:
 > > 
 > >   http://gcc.gnu.org/ml/gcc-patches/2000-08/msg00907.html
 > 
 > Yes.  I haven't looked closely at it... will try it when I get a chance. 
 > Thanks.
 
 Andrew is confident enough that his patch won't hurt and I haven't
 seen regressions that can be tied to it. I'm checking it in because
 everyone is seriously itching about having this fixed.
 
 I verified that gcj/252 and 160 are fixed by this patch and I'm going to
 close these PRs. I don't handily have access to Alpha hardware -- I'll
 let you verify that this patch fixes 252.
 
 ./A

From: Jeff Sturm <jeff.sturm@appnet.com>
To: apbianco@redhat.com
Cc: bryce@albatross.co.nz, aph@cygnus.com, java-gnats@sourceware.cygnus.com
Subject: Re: gcj/321
Date: Thu, 31 Aug 2000 15:59:13 -0400

 Alexandre Petit-Bianco wrote:
 > I verified that gcj/252 and 160 are fixed by this patch and I'm going to
 > close these PRs. I don't handily have access to Alpha hardware -- I'll
 > let you verify that this patch fixes 252.
 
 It does.  Thanks.
 
 --
 Jeff Sturm
 jeff.sturm@appnet.com

From: Alexandre Petit-Bianco <apbianco@cygnus.com>
To: java-gnats@sourceware.cygnus.com
Cc:  
Subject: Re: gcj/321
Date: Tue, 5 Sep 2000 18:12:42 -0700 (PDT)

 [It's java-gnats, not java-prs]
 
 Jeff Sturm writes:
 >  > close these PRs. I don't handily have access to Alpha hardware -- I'll
 >  > let you verify that this patch fixes 252.
 
 Oops. I meant 214.
 
 >  It does.  Thanks.
 
 You meant 214?
 
 ./A
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="Foo.java"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Foo.java"

cHVibGljIGNsYXNzIEZvbyB7CglwdWJsaWMgaW50IGZvbyhpbnQgbikgewoJCXN3aXRjaCAobikg
ewoJCQljYXNlIC0xOgoJCQljYXNlIDA6CgkJCWNhc2UgMToKCQkJCXJldHVybiAxOwoJCX0KCQly
ZXR1cm4gMDsKCX0KfQo=


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]