This is the mail archive of the
gcc-prs@gcc.gnu.org
mailing list for the GCC project.
Re: java/5794: gcj fails to verify .class file generated by Sun JDK 1.4 compiler
- From: Tom Tromey <tromey at redhat dot com>
- To: nobody at gcc dot gnu dot org
- Cc: gcc-prs at gcc dot gnu dot org,
- Date: 1 Mar 2002 00:26:02 -0000
- Subject: Re: java/5794: gcj fails to verify .class file generated by Sun JDK 1.4 compiler
- Reply-to: Tom Tromey <tromey at redhat dot com>
The following reply was made to PR java/5794; it has been noted by GNATS.
From: Tom Tromey <tromey@redhat.com>
To: adam@medovina.org
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: java/5794: gcj fails to verify .class file generated by Sun JDK 1.4 compiler
Date: 28 Feb 2002 17:47:43 -0700
>>>>> "Adam" == adam <adam@medovina.org> writes:
Adam> Number: 5794
Adam> Synopsis: gcj fails to verify .class file generated by Sun JDK 1.4 compiler
Could you upload the resulting .class file?
Just reply to this email and attach it, keeping gcc-gnats on the CC
line.
Adam> When Sun's Java compiler in JDK 1.4 compiles a try...finally
Adam> block, it emits a (useless and unused) exception table entry
Adam> whose target is within the range of protected instructions.
Adam> There is nothing inherently unsafe with this, but we check for
Adam> this case and reject it in verify.c.
It seems to me that this must be invalid.
Adam> I tried that and then gcj complained about a stack overflow in
Adam> the same .class file.
Yeah. Suppose the VM encounters an internal error and throws an
exception after it has set the PC to the start of the exception
handler but before the first instruction of the handler (probably a
pop or an astore) is executed. This leads inexorably to a stack
overflow. I imagine the gij verifier will die on this too.
I'd like to see the class file though. It's possible there are
obscure extenuating circumstances. Or perhaps they've tightened the
verification spec and I don't yet know about it.
Tom