[kaffe] completed bytecode verifier!

[Timothy Stack]

> Hi Tim,

hi,

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

Thanks, I understood it just fine.

> 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?).

Its broken...  It should return NULL immediately if classFromSig fails to 
load the class.  And the check for "consuming all characters in string" 
should be done by the verifier.  And, it might leak memory since it 
doesn't call discardErrorInfo...  Anyways...

> 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,

I don't think this will work with user loaders since getClass() calls
loadClass(), which can call a user loader, which can do whatever it wants.

> 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?

I think the circularity checking is broken, its just checking to see if 
there is a loop in calls to loadClass and not checking that its still 
trying to load the super class.  For example, in this case CMember would 
have finished loading its super (java.lang.Object) so there is no 
circularity.

I'm thinking the fix would involve a new class state and classEntry state 
that break up the loading of the super class.  I'll try to look at it more 
over the weekend...

> Greetings,
> Helmer

tim