[Mono-dev] 1147 Ways To Break A Runtime

[Jim Purbrick]

Hi Paolo/All,

New archive here:

http://homepage.ntlworld.com/james.purbrick/VerifierTests6.tar

I've added tests for loading overlapped fields, boxing
byref types and other exotica, tidied up the scripts
so they are much clearer and simpler and fixed a load
of tests. All the tests bar those which reference
non-existent fields and methods now assemble with Mono
ilasm and all the resultant exes give (only) the
expected verification errors when run through MS
peverify /IL (although MS peverify seems fine about
stack merging native ints with int32s and loading
initonly fields).

> Would you mind extracting the IL template source in
> their own files? Maybe something called 
> testtype.iltmpl. This way it's easier to look at 
> them.

Hmm, I like having the templates in the scripts to
keep  them encapsulated and I think it's easier to
keep the markers in the templates and substitution
commands in sync that way. I've added some white space
between the script commands and templates in the
scripts though, so it's easier to see the CIL now.

> Note that at least some templetes are invalid:
> in make_bin_test.sh the signature of Main() is
> parametrized, but this is not allowed, since only no

> args or string[] is accepted.

I think I've fixed this now.

> The attached Makefile is what I temporarily use

I don't think I got the attachment. I've hacked
together some scripts for now. I'll leave the decision
as to how you want to integrate the tests with the
Mono SVN tree up to you.

> Or, another option that would make testing much
> faster: instead of having independent il programs, 
> make them compile to a library and generate a C# 
> driver program that calls each function with a try
{}
> catch (ExpectedException) {} clause. This can't be 
> done for all the tests, though ...

It also makes it more difficult to run through other
external verifiers or runtime verifiers which don't
through the same exception. I think it's useful to be
able to compare results from the different verifiers,
so I think we should keep the tests as separate CIL
files.

> It is always possible to merge two references to
> Object. This doesn't mean that the later uses of 
> this object are verifiable. Say that a callvirt is 
> done on the object to MyMethod (): this call won't 
> be verifiable, because Object doesn't define a 
> MyMethod () method. Hope this clears things up.

Yes, thanks. I'm going to need a test that's a bit
more involved than the current 10 line CIL snippets
for this one... ;-)

> Not sure what you mean by slot type. The type of the
> target field/local/etc must be compatible with the 
> stack type of the values that is going to be stored 
> to it.

Yes. I needed to read partition I to clear this up.
I,8.7 says that values either need to be assignment
compatible with locations or it needs to be possible
to coerce the value so it is compatible. So, I need
another set of tests for assignment compatibility.
I'll do those tomorrow.

Cheers,

Jim.


	
	
		
___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com