This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Patch: FYI: libgcj verifier bug fix
- From: Tom Tromey <tromey at redhat dot com>
- To: java-patches at gcc dot gnu dot org
- Date: 03 Mar 2003 16:12:23 -0700
- Subject: Patch: FYI: libgcj verifier bug fix
- Reply-to: tromey at redhat dot com
I'm checking this in to the 3.3 branch and the trunk.
This fixes a fairly obscure bug in the libgcj verifier.
It is ok for a `jsr' to be the last bytecode instruction in a method,
provided that the corresponding subroutine never returns.
There is a new test case in Mauve.
The IBM 1.3 JDK verifier passes this too. Interestingly, the bytecode
in question causes the Sun 1.4 JDK to crash.
Tom
Index: ChangeLog
from Tom Tromey <tromey at redhat dot com>
* verify.cc (handle_jsr_insn): Don't fail if `jsr' appears at end
of bytecode.
(handle_ret_insn): Fail if returning to jsr that appears at end of
bytecode.
Index: verify.cc
===================================================================
RCS file: /cvs/gcc/gcc/libjava/verify.cc,v
retrieving revision 1.51
diff -u -r1.51 verify.cc
--- verify.cc 16 Feb 2003 19:34:49 -0000 1.51
+++ verify.cc 3 Mar 2003 23:16:44 -0000
@@ -1526,6 +1526,12 @@
for (subr_info *subr = jsr_ptrs[csub]; subr != NULL; subr = subr->next)
{
+ // We might be returning to a `jsr' that is at the end of the
+ // bytecode. This is ok if we never return from the called
+ // subroutine, but if we see this here it is an error.
+ if (subr->pc >= current_method->code_length)
+ verify_fail ("fell off end");
+
// Temporarily modify the current state so it looks like we're
// in the enclosing context.
current_state->subroutine = get_subroutine (subr->pc);
@@ -1575,16 +1581,15 @@
// the local variable state across the jsr, but the subroutine
// might change the stack depth, so we can't make any assumptions
// about it. So we have yet another special case. We know that
- // at this point PC points to the instruction after the jsr.
-
- // FIXME: what if we have a jsr at the end of the code, but that
- // jsr has no corresponding ret? Is this verifiable, or is it
- // not? If it is then we need a special case here.
- if (PC >= current_method->code_length)
- verify_fail ("fell off end");
-
- current_state->stacktop = state::NO_STACK;
- push_jump_merge (PC, current_state);
+ // at this point PC points to the instruction after the jsr. Note
+ // that it is ok to have a `jsr' at the end of the bytecode,
+ // provided that the called subroutine never returns. So, we have
+ // a special case here and another one when we handle the ret.
+ if (PC < current_method->code_length)
+ {
+ current_state->stacktop = state::NO_STACK;
+ push_jump_merge (PC, current_state);
+ }
invalidate_pc ();
}