This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Patch: FYI: libgcj verifier bug fix


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 ();
   }
 


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