This is the mail archive of the java-discuss@sourceware.cygnus.com 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]

Re: jc1 segfaults compiling volano


> Date: Tue, 22 Jun 1999 18:16:35 +1200
> From: Bryce McKinlay <bryce@albatross.co.nz>
> 
> As part of my ongoing effort to get the "volano" benchmark
> (ftp://ftp.volano.com/vmark2_1_2_0.class) to work on gcj (Volano
> consists of some rather nasty obfuscated classes), I have encountered
> two seperate segfaults trying to compile the "volano" benchmark :
> 
> Unfortunatly, we get another segfault further down the track, in
> COM/volano/mbi.class:

Try this patch.  Let me know how you get on.

Andrew.

Index: verify.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gcc/java/verify.c,v
retrieving revision 1.43
diff -c -2 -p -r1.43 verify.c
*** verify.c	1999/06/21 15:20:46	1.43
--- verify.c	1999/06/22 14:42:24
*************** verify_jvm_instructions (jcf, byte_ops, 
*** 428,431 ****
--- 428,492 ----
  	  INVALIDATE_PC;
  	}
+       /* Check if there are any more pending blocks in the current
+ 	 subroutine.  Because we push pending blocks in a
+ 	 last-in-first-out order, and because we don't push anything
+ 	 from our caller until we are done with this subroutine or
+ 	 anything nested in it, then we are done if the top of the
+ 	 pending_blocks stack is not in a subroutine, or it is in our
+ 	 caller. */
+       if (current_subr 
+ 	  && PC == INVALID_PC)
+ 	{
+ 	  tree caller = LABEL_SUBR_CONTEXT (current_subr);
+ 
+ 	  if (pending_blocks == NULL_TREE
+ 	      || ! LABEL_IN_SUBR (pending_blocks)
+ 	      || LABEL_SUBR_START (pending_blocks) == caller)
+ 	    {
+ 	      int size = DECL_MAX_LOCALS(current_function_decl)+stack_pointer;
+ 	      tree ret_map = LABEL_RETURN_TYPE_STATE (current_subr);
+ 	      tmp = LABEL_RETURN_LABELS (current_subr);
+ 	      
+ 	      /* FIXME: If we exit a subroutine via a throw, we might
+ 		 have returned to an earlier caller.  Obviously a
+ 		 "ret" can only return one level, but a throw may
+ 		 return many levels.*/
+ 	      current_subr = caller;
+ 
+ 	      if (RETURN_MAP_ADJUSTED (ret_map))
+ 		{
+ 		  /* Since we are done with this subroutine , set up
+ 		     the (so far known) return address as pending -
+ 		     with the merged type state. */
+ 		  for ( ; tmp != NULL_TREE;  tmp = TREE_CHAIN (tmp))
+ 		    {
+ 		      tree return_label = TREE_VALUE (tmp);
+ 		      tree return_state = LABEL_TYPE_STATE (return_label);
+ 		      if (return_state == NULL_TREE)
+ 			{
+ 			  /* This means means we had not verified the
+ 			     subroutine earlier, so this is the first jsr to
+ 			     call it.  In this case, the type_map of the return
+ 			     address is just the current type_map - and that
+ 			     is handled by the following PUSH_PENDING. */
+ 			}
+ 		      else
+ 			{
+ 			  /* In this case we have to do a merge.  But first
+ 			     restore the type_map for unused slots to those
+ 			     that were in effect at the jsr. */
+ 			  for (index = size;  --index >= 0; )
+ 			    {
+ 			      type_map[index] = TREE_VEC_ELT (ret_map, index);
+ 			      if (type_map[index] == TYPE_UNUSED)
+ 				type_map[index]
+ 				  = TREE_VEC_ELT (return_state, index);
+ 			    }
+ 			}
+ 		      PUSH_PENDING (return_label);
+ 		    }
+ 		}
+ 	    }
+ 	}
        if (PC == INVALID_PC)
  	{
*************** verify_jvm_instructions (jcf, byte_ops, 
*** 450,453 ****
--- 511,516 ----
  	VERIFICATION_ERROR ("falling through end of method");
  
+       /* fprintf (stderr, "** %d\n", PC); */
+ 
        oldpc = PC;
  
*************** verify_jvm_instructions (jcf, byte_ops, 
*** 1208,1272 ****
            return 0;
          }
- 
- 	      /* Check if there are any more pending blocks in this subroutine.
- 		 Because we push pending blocks in a last-in-first-out order,
- 		 and because we don't push anything from our caller until we
- 		 are done with this subroutine or anything nested in it,
- 		 then we are done if the top of the pending_blocks stack is
- 		 not in a subroutine, or it is in our caller. */
-       if (current_subr 
- 	  && PC == INVALID_PC)
- 	{
- 	  tree caller = LABEL_SUBR_CONTEXT (current_subr);
- 
- 	      if (pending_blocks == NULL_TREE
- 		  || ! LABEL_IN_SUBR (pending_blocks)
- 		  || LABEL_SUBR_START (pending_blocks) == caller)
- 		{
- 	      int size = DECL_MAX_LOCALS(current_function_decl)+stack_pointer;
- 	      tree ret_map = LABEL_RETURN_TYPE_STATE (current_subr);
- 	      tmp = LABEL_RETURN_LABELS (current_subr);
- 	      
- 	      /* FIXME: If we exit a subroutine via a throw, we might
- 		 have returned to an earlier caller.  Obviously a
- 		 "ret" can only return one level, but a throw may
- 		 return many levels.*/
- 	      current_subr = caller;
- 
- 	      if (RETURN_MAP_ADJUSTED (ret_map))
- 		{
- 		  /* Since we are done with this subroutine , set up
- 		     the (so far known) return address as pending -
- 		     with the merged type state. */
- 		  for ( ; tmp != NULL_TREE;  tmp = TREE_CHAIN (tmp))
- 		    {
- 		      tree return_label = TREE_VALUE (tmp);
- 		      tree return_state = LABEL_TYPE_STATE (return_label);
- 		      if (return_state == NULL_TREE)
- 			{
- 			  /* This means means we had not verified the
- 			     subroutine earlier, so this is the first jsr to
- 			     call it.  In this case, the type_map of the return
- 			     address is just the current type_map - and that
- 			     is handled by the following PUSH_PENDING. */
- 			}
- 		      else
- 			{
- 			  /* In this case we have to do a merge.  But first
- 			     restore the type_map for unused slots to those
- 			     that were in effect at the jsr. */
- 			  for (index = size;  --index >= 0; )
- 			    {
- 			      type_map[index] = TREE_VEC_ELT (ret_map, index);
- 			      if (type_map[index] == TYPE_UNUSED)
- 				type_map[index]
- 				  = TREE_VEC_ELT (return_state, index);
- 			    }
- 			}
- 		      PUSH_PENDING (return_label);
- 		    }
- 		}
- 	    }
- 	}
  
        prevpc = oldpc;
--- 1271,1274 ----

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