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
