1

Closed

mosacl Fails To Resolve mscorlib On Win64 When mosacl Executes As AnyCpu

description

I discovered this in Mosa.Runtime.Loader.AssemblyLoader while running the test cases on x64 Win7 with VS2008 and Icarus GUI Test Runner - all attempts at mosacl usage fail because the assembly-resolving code in mosacl can't find mscorlib. Specifically, the only one it finds is the one in %windows%\Microsoft.NET\Framework64 , which is a 64-bit PE and the Mosa PE-loading code cannot handle the format.
 
Any single one of the following workarounds should work (I've tried a couple):
 
  • Have a 32bit PE of mscorlib in the working directory while you are running the MOSA compiler
  • Compile mosacl with x86 build configuration instead of AnyCpu to force MOSA compiler to run under 32bit
  • Use 'corflags' MS.NET utility to manually mark mosacl to require 32bit mode
  • Compile test-case assembly with x86 build configuration instead of AnyCpu to force MOSA compiler to run under 32bit
  • Use 'corflags' MS.NET utility to manually mark test-case assembly to require 32bit mode
     
    Long-term issues:
     
  • We need to implement PE32+
  • We need to make the assembly resolving code more intelligent about how it looks for an assembly to resolve a reference
     
    Its important to keep in mind that while related, this has nothing to do with mosacl cross-compiling for x64 - and more of making sure that the compiler runs on .NET supported platforms.
Closed Aug 29, 2009 at 1:45 AM by illuminus86
I'm closing this issue in lieu of a more concise one worded to drive this home.

comments

54616E6E6572 wrote Aug 21, 2009 at 5:25 PM

Just as a side note, to make it easier on whoever fixes this, the compiler fails when it checks the magic number (offset 0) in the optional header, where on a 64-bit (PE32+) platform the magic number is 0x20, and on a 32-bit (PE32) platform the magic number is 0x10. PE32+ also removes and adds several fields and resizes several of the pointers to the 8-byte size.

illuminus86 wrote Aug 23, 2009 at 4:13 AM

Could you provide a unified diff for your patch please? I'm not having much luck trying to use the CodePlex client to apply the patch you've uploaded. Thanks!

moitoius wrote Aug 24, 2009 at 11:00 AM

You asked for comments :).

Option 2 (Compile mosacl with x86 build configuration) is actually recommended. Using 64bit if you don't need it is a bad practice (sorry, no references - read about it while back). You should only be using it if you are going to be hitting the 2GB (correct?) cap - using 64bit if you don't need it is a waste (it naturally uses more memory - especially in .Net).

Agreed and disagreed - Agreed: it needs to be fixed in the long run; especially when x64 runtime development starts. Disagreed: The reason we have 64bit PE files is to support 64bit interop and IJW MC++; if something is targeted to x64 explicitly there is a extremely good chance we won't be able to run it because of native or interop code that is contained within it - it's a Windows compatibility (and most probably Mono leverages it too) thing.

That being said 32bit and AnyCPU are probably the ones you want to get right straight away.

illuminus86 wrote Aug 25, 2009 at 1:29 PM

It's a subjective argument, because the amount of extra RAM consumed is nominal, but you get the bonus of the .NET JIT having more registers to squeeze your variables into - making the compiler run faster. Running in x64 is the default behavoir on Win64 - and if we want to support it as a development platform (regardless as to whether or not it is a target platform for code our compiler compiles) then we should spend a little energy on it working.

illuminus86 wrote Aug 29, 2009 at 1:42 AM

Patch submitted by tanner has been applied, and I made some additions that were needed for PE32+ support to actually work.

However, PE32+ support does not seem to be enough to get the compiler to compile the assembly correctly, and every single testcase fails (though the Framework64 version of corlib appears to be successfully loading). The core of this issue is left unresolved - the assembly loader needs to reject the Framework64 folder as a candidate for assembly resolution.

wrote Aug 29, 2009 at 1:45 AM

wrote Feb 13, 2013 at 8:45 PM

wrote May 16, 2013 at 2:11 AM