[Mono-list] Mono doesn't seem to like JSharp code in MSIL form. -> BANG

[Paolo Molaro]

On 02/20/03 Miguel de Icaza wrote:
> > I'll add a message that will get printed when the #- heap is found:
> > you need to compile the assemblies without the /incremental switch
> > (use the Release mode instead of the Debug one). The #- heap is an
> > internal MS format that is not standardized. Some info was posted to
> > this list a while ago: it should not be hard to support it in mono, but
> > I don't have the time to implement it right now. Any volunteers?
> 
> I do not remember reading anything that would contain useful information
> about the #- heap.  Could you post your thoughts on this?

Serge posted some useful info a while back, including the name of the
additional tables (FieldPtr, MethodPtr, etc). I think his PE-reading
code also has the table index values.
He also posted the instructions to get csc to produce binaries with that
heap, so that we can produce them at will and check the format: given
two files to compile, these commands will generate it:
        csc -out:bin.exe -debug+ -optimize- -incremental+ a.cs b.cs
        touch a.cs
        csc -out:bin.exe -debug+ -optimize- -incremental+ a.cs b.cs
			
Then, since they call it uncompressed, I assume the column values have a
fixed size of 4 bytes integers instead of following the normal rules
for compression (implemented in mono in mono_metadata_compute_size ()).
Also, a few days ago I had an idea about how they could use the FieldPtr
and related tables. In the normal #~ heap for each type you have the
FieldList column that points at the first field for the type, all the
other fields are layed out sequentially after that, until the end of the
table or until the first field of another type. With incremental
compilation this is not possible, since the fields may be created out of
order. So I guess they use the FieldPtr table as a linked list.

The FieldPtr table has two columns both of which are indexes in the Field
Table. The FieldList column in the TypeDef table points to the first
field for the type as usual, but to find the next field, you have to
lookup the row in FieldPtr with the same field index in the first column
and you'll use the field index in the second column to find the next
field for the type.
The same process can be applied to MethodPtr, EventPtr and the like.
Mind you, I haven't checked yet with a real #- heap if the above ideas
are correct, but maybe this info can be helpful for some enterprising
contributor:-)

Of course, the MS people listening should feel free to correct any
mistakes in the description or better yet provide us the documentation
for the format:-)

lupus

-- 
-----------------------------------------------------------------
lupus@debian.org                                     debian/rules
lupus@ximian.com                             Monkeys do it better