Re: java/5794: gcj fails to verify .class file generated by Sun JDK 1.4 compiler

Re: java/5794: gcj fails to verify .class file generated by Sun JDK 1.4 compiler

[tromey]

Synopsis: gcj fails to verify .class file generated by Sun JDK 1.4 compiler

Responsible-Changed-From-To: unassigned->tromey
Responsible-Changed-By: tromey
Responsible-Changed-When: Wed Sep 11 12:41:40 2002
Responsible-Changed-Why:
    I'm handling the administrivia
State-Changed-From-To: open->closed
State-Changed-By: tromey
State-Changed-When: Wed Sep 11 12:41:40 2002
State-Changed-Why:
    Thanks for your report.
    Andrew recently checked in a fix which allows this
    bytecode but issues a warning.
    This will appear in gcc 3.3.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5794

java/5794: gcj fails to verify .class file generated by Sun JDK 1.4 compiler

[adam]

>Number:         5794
>Category:       java
>Synopsis:       gcj fails to verify .class file generated by Sun JDK 1.4 compiler
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          rejects-legal
>Submitter-Id:   net
>Arrival-Date:   Thu Feb 28 12:15:59 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     Adam Dingle
>Release:        gcc version 3.0.2 20010905 (Red Hat Linux 7.1 3.0.1-3)
>Organization:
>Environment:
Red Hat Linux 7.2 on a Pentium PC
>Description:
If I use Sun's Java compiler (from JDK 1.4) to compile a .java file containing a try...finally block, then try to use gcj to compile the .class file into executable code, gcj complains with the error message "bad pc in exception_table".

Here's what's going on.  Recall that a Java .class file contains an exception table for each method.  Each entry in the exception table contains a range (from, to) of instructions to protect as well as a target instruction to jump to if an exception occurs within that range.  When Sun's Java compiler in JDK 1.4 compiles a try...finally block, it emits a (useless and unused) exception table entry whose target is within the range of protected instructions.  There is nothing inherently unsafe with this, but we check for this case and reject it in verify.c.

Unfortunately, the fix is apparently not as simple as removing the line which makes this check (the line "|| (handler_pc >= start_pc && handler_pc < end_pc)" in verify_jvm_instructions() in verify.c); I tried that and then gcj complained about a stack overflow in the same .class file.  I don't have time to look at the verification code more right now, so I'm filing a bug report in case someone else wants to pick up where I left off.
>How-To-Repeat:
$ /usr/java/j2sdk1.4.0/bin/javac Foo.java
$ gcj Foo.class
Foo.java: In class `Foo':
Foo.java: In method `Foo.invoke()':
Foo.java:6: bad pc in exception_table
$ 
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: text/x-java; name="Foo.java"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Foo.java"

cHVibGljIGNsYXNzIEZvbwp7CglwdWJsaWMgaW50IGludm9rZSgpCgl7CgkJdHJ5IHsKCQkJcmV0
dXJuIDE7CgkJfSAgZmluYWxseSB7CgkJCXJldHVybiAyOwoJCX0KCX0KfQo=