[kaffe] completed bytecode verifier!

[Helmer Krämer]

This is a multi-part message in MIME format.

--Multipart_Fri__8_Aug_2003_09:51:23_+0200_09da1e48
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Thu, 7 Aug 2003 09:46:31 -0600 (MDT)
Timothy Stack <stack@cs.utah.edu> wrote:

Hi Tim,

> > I just committed the bytecode verifier.  It's a huge chunk of code and
> > it's very likely that there are little bugs lurking around in it...I can't
> > even count how many off-by-one errors I had during development.
> 
> make  check-TESTS
> make[1]: Entering directory `/z/stack/tmp0/kbuild/test/regression'
> PASS: HelloWorldApp.class.save
> error compiling:
> java.lang.NoClassDefFoundError: Lat/dms/kjc/KjcSignatureParser;
>    <<No stacktrace available>>
> FAIL: HelloWorldApp.java
> error compiling:
> java.lang.NoClassDefFoundError: Lat/dms/kjc/KjcSignatureParser;
>    <<No stacktrace available>>
> FAIL: TestIntLong.java
> error compiling:
> java.lang.NoClassDefFoundError: Lat/dms/kjc/KjcSignatureParser;
>    <<No stacktrace available>>

I think I managed to figure out what is going wrong here.
Hopefully my explanations will not get too confusing.

First of all, you might consider applying the attached patch,
since it will give you some better error messages in case some
type could not be resolved during verification (do you know why
getClassFromSignature throws away the einfo from classFromSig?).

If you try running $JAVA at.dms.kjc.CSourceClass afterwards,
you will see that kaffe thinks that it has detected a
ClassCircularityError.

Now comes the confusing part, since I'll try to explain what
I think is going on here ;)

First of all, CSourceClass is derived from CClass, which is derived
from CMember (all in package at.dms.kjc). So when kaffe has to load
CSourceClass, that will trigger loading CClass and loading CClass in
turn will trigger loading CMember. This will cause kaffe to process
CMember to state CSTATE_LINKED, while CSourceClass and CClass are
both in the CSTATE_LOADED_SUPER state (and their classMappingState
is NMS_LOADING).

Processing CMember to CSTATE_LINKED however, includes verifcation
of the class CMember (both, verify2 and verify3). But in order to
do this, the verifier has to resolve the types CSourceClass and
CClass (they are needed for type checking during verification of
the getAccessorOwner method). Since the verifier uses loadClass()
to resolve the type, the ClassCircularityError is thrown (because
classMappingSearch detects that the state is NMS_LOADING and that
the current thread is responsible for it).

Next problem is that the verifier needs a class that is at least
in state >= CSTATE_LOADED_SUPER (otherwise it could not check for
inheritance). 

An idea how to fix this? My guess would be to defer verification
of the superclass until after the subclass is in state CSTATE_LOADED_SUPER
(and NMS_LOADED). This could probably be done by creating a special
getClass() that returns a class that is only CSTATE_PREPARED, but not
CSTATE_LINKED. The subclass would load the superclass using this special
getClass(), set its own state to CSTATE_LOADED_SUPER (and NMS_LOADING)
and process the superclass to CSTATE_LINKED afterwards. That way, the
verifier would be able to properly resolve the subclass while verifying
the superclass, but detection of ClassCircularityErrors should still
work? 

Greetings,
Helmer
--Multipart_Fri__8_Aug_2003_09:51:23_+0200_09da1e48
Content-Type: application/octet-stream;
 name="emsg-patch"
Content-Disposition: attachment;
 filename="emsg-patch"
Content-Transfer-Encoding: base64

SW5kZXg6IGl0eXBlcy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9jdnMva2FmZmUva2FmZmUva2Fm
ZmUva2FmZmV2bS9pdHlwZXMuYyx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4yOApkaWZmIC11IC1y
MS4yOCBpdHlwZXMuYwotLS0gaXR5cGVzLmMJNyBBdWcgMjAwMyAyMTowNToyNyAtMDAwMAkxLjI4
CisrKyBpdHlwZXMuYwk4IEF1ZyAyMDAzIDA2OjM4OjQ1IC0wMDAwCkBAIC0yMDcsOCArMjA3LDgg
QEAKIAkgKiAuY2xhc3MgZmlsZSwgb3IgaXQgY291bGQgYmUgYSBtYWxmb3JtZWQgdXNlciBpbnB1
dCBmcm9tIAogCSAqIENsYXNzLmZvck5hbWUoKQogCSAqLwotCXBvc3RFeGNlcHRpb25NZXNzYWdl
KGVpbmZvLCBKQVZBX0xBTkcoTm9DbGFzc0RlZkZvdW5kRXJyb3IpLCAiJXMiLCBzaWcwKTsKLQly
ZXR1cm4gKDApOworCS8qcG9zdEV4Y2VwdGlvbk1lc3NhZ2UoZWluZm8sIEpBVkFfTEFORyhOb0Ns
YXNzRGVmRm91bmRFcnJvciksICIqJXMqIiwgc2lnMCk7CisJKi9yZXR1cm4gKDApOwogfQogCiAv
KgpJbmRleDogdmVyaWZ5LmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2N2cy9rYWZmZS9rYWZmZS9r
YWZmZS9rYWZmZXZtL3ZlcmlmeS5jLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjE4CmRpZmYgLXUg
LXIxLjE4IHZlcmlmeS5jCi0tLSB2ZXJpZnkuYwk3IEF1ZyAyMDAzIDIxOjA1OjI3IC0wMDAwCTEu
MTgKKysrIHZlcmlmeS5jCTggQXVnIDIwMDMgMDY6Mzg6NDcgLTAwMDAKQEAgLTQxOTQsNyArNDE5
NCw5IEBACiB7CiAJY2hhciogc2lnOwogCWNoYXIqIHRtcDsKLQkKKworCURCRyhWRVJJRlksIGRw
cmludGYoImFib3V0IHRvIHJlc29sdmUgdHlwZSAiKTsgcHJpbnRUeXBlKHR5cGUpOyBkcHJpbnRm
KCIgZm9yIGNsYXNzICVzXG4iLCBDTEFTU19DTkFNRSh0aGlzKSk7ICkKKwogCWlmICh0eXBlLT50
aW5mbyAmIENMQVNTX05BTUVTVFIpIHsKIAkJc2lnID0gKGNoYXIqKXR5cGUtPnR5cGU7CiAJCQpA
QCAtNDIxNSw2ICs0MjE3LDggQEAKIAkJdHlwZS0+dHlwZSA9IGdldENsYXNzRnJvbVNpZ25hdHVy
ZSgoY29uc3QgY2hhciAqKXR5cGUtPnR5cGUsIHRoaXMtPmxvYWRlciwgZWluZm8pOwogCQl0eXBl
LT50aW5mbyA9IDA7CiAJfQorCisJREJHKFZFUklGWSwgZHByaW50ZigicmVzb2x2ZWQgdHlwZSAi
KTsgcHJpbnRUeXBlKHR5cGUpOyBkcHJpbnRmICgiIGZvciBjbGFzcyAlc1xuIiwgQ0xBU1NfQ05B
TUUodGhpcykpOyApIAogfQogCiAKQEAgLTQ1MDcsMTAgKzQ1MTEsMTggQEAKIAkJcmV0dXJuIHRy
dWU7CiAJfQogCi0KKwlkaXNjYXJkRXJyb3JJbmZvIChlaW5mbyk7CiAJcmVzb2x2ZVR5cGUoZWlu
Zm8sIHRoaXMsIHQxKTsKKwlpZiAoZWluZm8tPnR5cGUpIHsKKwkJZHByaW50ZiAoImVycm9yIHJl
c29sdmluZyAiKTsgcHJpbnRUeXBlKHQxKTsgZHByaW50ZiAoIjogJXMsICVzXG4iLCBlaW5mby0+
Y2xhc3NuYW1lLCBlaW5mby0+bWVzcyk7CisJfQorCisJZGlzY2FyZEVycm9ySW5mbyAoZWluZm8p
OwogCXJlc29sdmVUeXBlKGVpbmZvLCB0aGlzLCB0Mik7Ci0JCisJaWYgKGVpbmZvLT50eXBlKSB7
CisJCWRwcmludGYgKCJlcnJvciByZXNvbHZpbmcgIik7IHByaW50VHlwZSh0Mik7IGRwcmludGYg
KCI6ICVzLCAlc1xuIiwgZWluZm8tPmNsYXNzbmFtZSwgZWluZm8tPm1lc3MpOworCX0KKwogCWlm
ICh0MS0+dHlwZSA9PSBOVUxMIHx8IHQyLT50eXBlID09IE5VTEwpIHsKIAkJREJHKFZFUklGWTMs
CiAJCSAgICBkcHJpbnRmKCIlc3R5cGVjaGVjayBFUlJPUjogdDEgPSAiLCBpbmRlbnQpOwo=

--Multipart_Fri__8_Aug_2003_09:51:23_+0200_09da1e48--