Re: [DotGNU]UnManaged Pointers stuff (was: Weekend Warriors)

[Rhys Weatherley]

Fergus Henderson wrote:
> 
> On 16-Oct-2002, Rhys Weatherley <address@hidden> wrote:
> >
> > UnveriableCode means nothing in pnet.  It exists to notify
> > MS'es CLR about the presence of "unsafe" constructs.  It does
> > not turn off the verifier.  Nothing turns off the verifier
> > in pnet - but it may act in different modes depending upon
> > how the assembly is loaded.
> 
> That seems like a bad design.  Running the verifier is a waste of time
> if the code is known to be unverifiable.  Checking the unverifiable code
> attribute is surely going to be a lot faster than running the verifier,
> isn't it?

The verifier in pnet feeds into the CVM code generator, so even
if strong type checking is disabled, it still needs to be run
to analyse the code prior to CVM generation.  I don't separate
verification and code generation, like most other VM's.

Anyway, the ECMA spec has two different terms that are important
here: "Correct CIL" and "Verifiable CIL".  Both are handled by
what I call a "verifier" with the "unsafeAllowed" flag used to
select between them (I named it a verifier before I fully
understood the difference).

In ECMA's terminology, "correct" means that the types of operands
are consistent, but that the instruction may violate GC heap
safety at runtime.  "Verifiable" means "correct plus safe".
Correct CIL may sometimes be referred to as "unverifiable",
but it is still necessary to type-check the instructions.

An example may be in order.  From the description of "ldfld":

   ldfld <field>

   Stack: ..., <obj> -> ..., <value>

   Verifiability:

   Correct CIL ensures that <field> is a valid token referring
   to a field, and that <obj> will always have a type compatible
   with that required for the lookup being performed.  For
   verifiable code, <obj> may not be an unmanaged pointer.

Implicit in the definition is also that Correct CIL requires
that there be one value on the stack, and that it be an object
reference or pointer (e.g. a float value is disallowed).

Even when in correct/unveriable modes, it is still necessary
to check the above conditions prior to CVM code generation.

> BTW, I assume there is a way to run unverifiable code in pnet, right?
> If so, what is it?  Is plain "ilrun foo.exe" enough?
> There doesn't seem to be any option to ilrun which would specify
> whether or not it's OK to run unverifiable code.

Right now, it always runs unverifiable code when you load
an assembly from a disk file.  This will change once we have
the ability to download applet-style assemblies.

> P.S. The Mercury compiler's .NET back-end currently generates unverifiable
> code.  There's an option to generate verifiable code, but it is not yet
> fully implemented, and will result in slower code.

Since Mercury's code (presumably) conforms with the "Correct CIL"
requirements, there shouldn't be any problem.  If there are
problems, they are most likely due to bugs rather than the verifier.

Cheers,

Rhys.