[kaffe] completed bytecode verifier!

[Helmer Krämer]

On Thu, 7 Aug 2003 09:46:31 -0600 (MDT)
Timothy Stack <stack at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: emsg-patch
Type: application/octet-stream
Size: 1877 bytes
Desc: not available
Url : http://pogo.kaffe.org/pipermail/kaffe/attachments/20030808/7558103c/emsg-patch-0002.obj