Posted
3 months
ago
by
illuminus86
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.
... [More]
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.
Comments: I'm closing this issue in lieu of a more concise one worded to drive this home. [Less]
Posted
3 months
ago
by
illuminus86
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.
... [More]
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.
Comments: ** Comment from web user: illuminus86 ** 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. [Less]
Posted
3 months
ago
by
illuminus86
Small patch from tanner that adds support for PE32+
Posted
3 months
ago
by
illuminus86
illuminus86 has applied patch #3710.
Comment:
Helps load PE32+ (after some additional modifications). Does not actually fix issue #24399 though, because of further problems with the compiler.
Posted
3 months
ago
by
illuminus86
illuminus86 has declined patch #3660.
Comment:
Unable to apply due to patch format.
Posted
3 months
ago
by
54616E6E6572
54616E6E6572 has uploaded a patch.
Description:
Same as before mosacl will now correctly compile and run on Win64. Should support any PE32/PE32+ file with CLR extensions. This one is made using GNU diff at the request of several users.
Posted
4 months
ago
by
illuminus86
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.
... [More]
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.
Comments: ** Comment from web user: illuminus86 ** 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. [Less]
Posted
4 months
ago
by
moitoius
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.
... [More]
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.
Comments: ** Comment from web user: moitoius ** 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. [Less]
Posted
4 months
ago
by
illuminus86
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.
... [More]
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.
Comments: ** Comment from web user: illuminus86 ** 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! [Less]
Posted
4 months
ago
by
illuminus86
When executing mosacl with the following parameters:
-o Mosa.Kernel.exe --Architecture=x86 -b=mb0.7 --format=ELF32 Mosa.Kernel.dll
A LinkerException with message "Load and virtual section alignment must be
... [More]
identical if you are booting non-ELF binaries with a multiboot bootloader" is generated in Multiboot0695AssemblyStage.WriteMultibootHeader()
Assuming that the error message is correct, this is a flaw in the code's attempt to check which linker is actually in use. When I break on the exception and take a look, the IAssemblyLinker that is being checked (to determine if Elf32 or Elf64 are in use) is an instance of LinkerFormatSelector , which wraps an underlying true implementation of what in this case is Elf32.
Work Around Suggestion
------------------------------
Currently everyone seems to be used to passing parameters to mosacl that make LoadSectionAlignment and VirtualSectionAlignment equal each other, but as you can tell, I've omitted them.
Solution Suggestion
-----------------------
Make Multiboot0695AssemblyStage.WriteMultibootHeader() aware of the underlying linker implementation's type. This can be done with the addition of a public property to LinkerFormatSelector and an 'if' check in Multiboot0695AssemblyStage.WriteMultibootHeader(), but I don't want to pollute the meticulous architecture without feedback first.
Comments: Resolved with changeset 58318. [Less]
