This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: verification problems
- From: Tom Tromey <tromey at redhat dot com>
- To: Nic Ferrier <nferrier at tapsellferrier dot co dot uk>
- Cc: java at gcc dot gnu dot org
- Date: 28 Jan 2002 17:31:06 -0700
- Subject: Re: verification problems
- References: <87y9iixcvj.fsf@tf1.tapsellferrier.co.uk>
- Reply-to: tromey at redhat dot com
>>>>> "Nic" == Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:
Nic> fatal error: verification failed at PC 264 in gnu.socketserver.Server:serviceSocket(()Z): subroutines merged
Nic> If someone tells me what this error means I'll have a go at
Nic> tracking it down myself.
The JVMS says that two subroutines can't merge their returns to a
single `ret' instruction. So this is invalid:
jsr 31
return
jsr 25
return
25:
blah
goto 31
31: ret
I fixed one bug in this area yesterday.
However, further thought has convinced me to change my mind again --
now I think our approach to handling this situation is incorrect. We
check this constraint on an instruction-by-instruction basis, while
the JVMS only requires us to do so at a `ret' instruction. I think
this means that if the subroutine has no `ret' (for instance, suppose
insn 31 above was `return' or `athrow'), then the merging is fine.
Can you send me the `jcf-dump -c' output for the class in question?
I'd like to take a look at it.
Tom