From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11749 invoked by alias); 28 Feb 2002 20:16:10 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 11629 invoked by uid 71); 28 Feb 2002 20:16:02 -0000 Resent-Date: 28 Feb 2002 20:16:01 -0000 Resent-Message-ID: <20020228201601.11614.qmail@sources.redhat.com> Resent-From: gcc-gnats@gcc.gnu.org (GNATS Filer) Resent-To: nobody@gcc.gnu.org Resent-Cc: gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org, java-prs@gcc.gnu.org Resent-Reply-To: gcc-gnats@gcc.gnu.org, adam@medovina.org Received:(qmail 5675 invoked by uid 61); 28 Feb 2002 20:08:48 -0000 Message-Id:<20020228200848.5674.qmail@sources.redhat.com> Date: Thu, 28 Feb 2002 12:56:00 -0000 From: adam@medovina.org Reply-To: adam@medovina.org To: gcc-gnats@gcc.gnu.org X-Send-Pr-Version:gnatsweb-2.9.3 (1.1.1.1.2.31) Subject: java/5794: gcj fails to verify .class file generated by Sun JDK 1.4 compiler X-SW-Source: 2002-02/txt/msg00765.txt.bz2 List-Id: >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=