[Mono-list] mono_verify_corlib - Checking on non-standard fields - Why?

Paolo Molaro lupus@ximian.com
Thu, 2 Jan 2003 16:44:43 +0100

On 01/02/03 bvv wrote:
> Running mint I found that there's a check done on the corlib. 
> interp.c has a call to funciton "mono_verify_corlib" which is 
> found in verify.c.
> I was surprised to find that the verification involves checking if 
> certain "private" fields are present in various classes of corlib. 
> I say "private" because these fields are *NOT* part of the ECMA 
> standard class definitions.
> I stepped through Rotor code to see if they do they same thing, 
> and yes they do!
> If u try to replace Rotor's corlib with mono's corlib the checking 
> that Rotor does on the corlib fails because the *private* fields 
> that Rotor expects to find are either not available in mono's 
> corlib or the name of the field differs!
> Now, what i don't understand is
> What's the purpose of corlib verification?
> Why is corlib verification done based on such *private* fields?

The easiest and fastest way to communicate between the managed world and
the unmanaged world of the runtime is to lay out the things in memory in
a way that is understood by both worlds. Many types that are tightly
coupled with the runtime implementation (such as String, Type, the
Reflection and Reflection.Emit stuff and so on) have the same memory
layout in the managed and unmanaged world: mono_verify_corlib ()
checks that this is the case (not all the fields and types are checked
yet, though).
As a trivial example, consider the System.String class: there is one
field declared in the C# side of things: length. This field is accessed by the
string class code, but it is also accessed (and set) by the runtime, in
C code. Now, you could access it in C code by queyring the metadata for
the offset of the field and accessing it with address arithmetric and an
indirect load/store (in the early days of mono we used to do that and I bet
we still do it for some types somewhere). It's ways better to define a C
struct that has the same layout as the managed string class, so that in
C code you can access the fields of the structure naturally: the code is
cleaner and faster.


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