[Mono-list] Reflection and .NET Metadata
kumpera at gmail.com
Fri Apr 13 12:00:30 UTC 2012
Take a look at mono's IL and metadata verifiers at mono/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.
> If it doesn't select the file in your browser, the path is:
> SLF\TypeSystems\Ecma-335 Common Type
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-list