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 < [email protected]> 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 - [email protected] > http://lists.ximian.com/mailman/listinfo/mono-list >
_______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
