[Mono-list] Reflection and .NET Metadata

[Rodrigo Kumpera]

Take a look at mono's IL and metadata verifiers at mono/metadata/verify.c
and mono/metadata/metadata-verify.c

On Fri, Apr 13, 2012 at 3:05 AM, Allen Copeland <
alexander.morou at alexandermorou.com> wrote:

> I wrote in three weeks ago asking about how mono loaded assemblies in
> Linux or other Operating Systems.
>
> I have a question for you all about validating a .NET metadata parser.
>  The ECMA-335 specification outlines every aspect of the spec;
> however, even with a spec it's possible to get it wrong. Given your
> presence within Mono's development, I figured you might be able to
> tell me what I can do to validate the parser I'm writing.
>
> When I wrote in on March 23rd, I was just eleven days into my journey
> through .NET Metadata.  Using a bit of code generation, the current
> setup involves the use of a state-machine generator which constructs
> the Table Stream ( #~ stream ) initial parse method, table interfaces
> and readers.  It goes through and checks the tables being read in,
> reads their counts, and sets up flags associated to the encoding/table
> sizes.  Once the tables are created, it goes through and sets their
> individual states.  The states are simple numeric values which relate
> to the various imports of the given table.  As an example, the
> TypeDefTable has 16 states, because there are four possible types of
> variable lengths: fields, methods, strings and type defs.  In the
> order they were listed, each occupies a state machine bit, when the
> state is 1, 3, 5, 7, 9, 11, 13, or 15 Fields are Four bytes long,
> otherwise they are two (field occupies bit zero of the machine state),
> methods would occupy bit one, thus when the state is 2, 3, 6, 7, 10,
> 11, 14 or 15 the indexes are four bytes, otherwise two.  The trend
> continues with the string heap (bit two) and table def or ref or spec
> (bit three) indices.
>
> The concept above is fairly simple, the project I'm working on focuses
> on reading metadata in, but now I need a way to validate its results
> (all 38 tables and signature types, now I need to work on IL).  The
> structure of these are immutable, because of the initial focus of
> reading the data (that and the idea of altering an existing library
> doesn't sit well with me.)
>
> The reason I'm wanting to validate this data is I was testing it on
> StandAloneSignatures on every dll contained within the .NET BCL and I
> kept getting odd information: pinned fields, byref types that had
> custom attributes following them, method refs that have stdcall and
> cdecl calling conventions, and so on.  I don't know how to validate
> whether these are correct results, so I figured I'd turn to someone
> for insight since the CLI spec doesn't indicate such up front (if it
> does, I missed something...)
>
> Any insight you can provide is appreciated.
>
> PS: Here's a link to the code relative to the example table described.
>
> http://abstractionproject.codeplex.com/SourceControl/changeset/view/12133#216915
>
> If it doesn't select the file in your browser, the path is:
> SLF\TypeSystems\Ecma-335 Common Type
> System\_Internal\Cli\Metadata\Tables\CliMetadataTypeDefinitionTable.cs
>
> PPS:
> The code uses a method call to do a right-shift, embarrassingly the
> code generator I wrote is a bit old and originally was focused on
> supplementing Microsoft's CodeDOM, and then focused on replacing it,
> but certain aspects of its code were still dependent on it: thus no
> Bit Shifting binary operators.
> _______________________________________________
> Mono-list maillist  -  Mono-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-list/attachments/20120413/45866a57/attachment.html>