[Mono-list] rotor/mono incompatibility

[Toby DiPasquale]

Miguel,

	So I just figured out the problem. Deep in the core header
handling code, it checks to see if the file length is not 0 and that the
pointer to the raw data + the size of the raw data is greater than the
file length. On the Rotor-generated PE file, this is false, and thus, it
doesn't error out. However, on the MCS-generated PE file, this __IS__ 
true, and so it errors out. 

Here are the results I am talking about:
(don't ask me what these mean yet; I just printed them out to check the
values)

alpha:~> clix thread_example.exe 

1: Rva = 8192
2: FileLength = 1860
3: NumberOfSections = 1
4: PointerToRawData = 512
5: SizeOfRawData = 1536
EXE is not Managed
alpha:~> head -6 rotor-output-head 

1: Rva = 8200
2: FileLength = 2560
3: NumberOfSections = 2
4: PointerToRawData = 512
5: SizeOfRawData = 1536
alpha:~> 

The first is the MCS-generated PE file, and the second is the text file
containing the redirected output of the execution of clix on the
Rotor-generated PE file (both made from the same C# source code).

One thing I did notice is that Rotor goes into this section over and over
again throughout the execution of the Rotor-generated PE file for
seemingly no reason (that I can see, yet, that is). I would think
it only needs to hit this section once, judging by the name of the
function (which I will save you from knowing). Another interesting
thing that I have no explanation for is that the MCS-generated code has a
value of 1 for NumberOfSections, but the Rotor-generated PE file always
has a value of 2 for that same field. That routine is entered 530 times in
the course of the execution of the Rotor-generated PE file, and
NumberOfSections is always 2 (the other values change somewhat throughout 
the execution).

These values represent parts of the NT (PE?) Header, so I can see why
Rotor would bomb out if they are not correct. However, their meanings are
not all clear to me, and I don't know much about C++, either. Having said
that, this is one of the most interesting problems I've worked on all
year, so you __know__ I'm not stopping until I find this bug! I'll let you
know when I've discerned something more concrete, such as the importance
of 2 in NumberOfSections or why MCS generates "too-small" PE files.

Also, whereas clix goes into that routine 530 times with the Rotor-gen'd
PE file, it bombs out after the first go 'round on the MCS-generated PE
file. This is to be expected; I merely mention it to be thorough. I am
going to cc the mailing list on this one, just so other people are aware
of the problem. 

P.S. It would be very helpful if you could just point me straight to the
section of code in Mono that is responsible for generating the PE
header, so I wouldn't have to spend a lot of time looking for it :) This
way, I can reference sections of Mono's code and the things it needs,
rather than beating around the bush, trying not to mention too much of
Rotor's internals. Thanks again!!

P.P.S. clix is Rotor's JIT execution engine, analogous to the
/usr/local/mono/bin/mono command for Mono.

<< T o b i a s   D i P a s q u a l e >>
web: http://cbcg.net/
mailto: anany@ece.villanova.edu
trade: Software Engineer 
skillset: Linux/BSD/UNIX/C/Java/Ruby