[Mono-dev] The State Of Mono Assembly Verification?

[Paolo Molaro]

On 02/17/06 Jim Purbrick wrote:
> http://homepage.ntlworld.com/james.purbrick/VerifierTests2.tar
[...]
> I think they do what you're after. Eventually we can
> get rid of the examplar tests and just use the
> templates, create_test_set scripts and individual
> tests where they make sense.

Thanks. Yes, once the templates are used we can
remove the old tests and put this stuff in svn so it can be
developed there and added to the build mechanism.

> I have a few questions regarding the remaining tests:
> 
> 1) Should the 1.8.1.3 tests to check that illegal
> stack merge failures are caught use the "Verification
> Type (in stack state)" types along with the 1.8.1.2.3
> rules for type compatibility? It looks like object

Yes.

> values should always merge as System.Object is always
> a supertype of both?

No. Say you have:

class A {}
class B : A {}
class C : B {}

Merging B and C will result in a B type, not Object.
The spec says: the closest common supertype.
If you need to merge C and string, then the closest supertype
is Object.

> 2) Should shift op tests be based on "Table 6: Shift
> Operations" (which makes sense) or "Table 5: Integer
> Operations" (which 3.58 and 3.59 refer to under
> "Correctness and Verifiability").

I'd say Table 6. Once we have all the tests we can also run them on the
MS runtime and see if they allow more cases (their runtime is less
strict in some cases than the spec anyway).

> 3) How do I test that boxing byref, byref-like and
> void types fails verification.

I'm not sure ilasm will allow it to compile, but you'd use:
	// load a compatible value if possible
	box [mscorlib]System.Void
	box [mscorlib]System.Int32&
	box [mscorlib]System.TypedReference

> 4) What are overlapped object reference fields and how
> do I define one for the ldfld and ldflda tests?

Overlapped fields are like unions in C.
Use something like:
[StructLayout (LayoutKind.Explicit)]
struct TestStructure2 {
        [FieldOffset (0)]
        object val;
        [FieldOffset (0)]
        int val2;
}

You can play with FieldOffset to overlap different fields with different
types.

> 5) Which stack types can be stored in valuetype
> fields? 1.6 seems to suggest that all stack parameter
> types should fail when stored in a field using stfld.

Only a value type with the same type should be allowed.
In several places in the standard they forget to mention that a value
type is allowed on the eval stack.

> 6) How do i generate by-ref and ref any fields in CIL
> for the 1.6 coercion tests for stfld?

Use:
	.field int32& val1
and
	.field [mscorlib]System.TypedReference val2

They are not allowed, so I'm not sure ilasm will compile them.
As above, some the cases will likely need to be tested using
a modified ilasm.

> 7) When does coercion happen? Just for stfld and
> method calls? Stloc and starg check the type on the
> stack and type of slot match using the 1.8.1.2.3 rules
> and the "Verfication Type" set of types from
> 1.8.1.2.1?

Coercion should happens every time there is a store, so calls,
stloc, starg, stfld, stsfld, stelem, box, stobj, cpobj, stind.

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better