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]
Posted
4 months
ago
by
illuminus86
Posted
4 months
ago
by
illuminus86
Filed under # 24400 : http://mosa.codeplex.com/WorkItem/View.aspx?WorkItemId=24400
See Issue - feedback requested. Thanks!
-Bruce Markham
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. [Less]
Posted
4 months
ago
by
54616E6E6572
54616E6E6572 has uploaded a patch.
Description:
mosacl will now correctly compile and run on Win64. Should support any PE32/PE32+ file with CLR extensions.
Posted
4 months
ago
by
54616E6E6572
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: 54616E6E6572 ** 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. [Less]
Posted
4 months
ago
by
illuminus86
Filed under # 24399 : http://mosa.codeplex.com/WorkItem/View.aspx?WorkItemId=24399
See Issue - feedback requested. Thanks!
-Bruce Markham
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. [Less]
Posted
4 months
ago
by
tgiphil
COM is a binary interface. Therefore COM is unlikely to be supported in MOSA. Anything behind COM interfaces will have to be re-written in C# (or some other CIL compiled language).
Posted
4 months
ago
by
54616E6E6572
So I had started some work on converting all P/INVOKES into C# and while doing so I ran across a possible problem.
Most of the classes at the lower end of the object hierarchy are portable and don't rely on any particular implementation. But
... [More]
the closer you get to the root of the Object hierarchy, (System.Object, System.AppDomain, etc...) the more and more the code becomes integrated into Microsoft's COM and the less compliant it becomes with CLI specification (ECMA-335).
In example, the Mono implementation of System.AppDomain, implements the System._AppDomain interface, which allows the user to Create, Define, Execute, Load, etc... Application Domains. The System._AppDomain interface is a child instance of the Microsoft COM IUnknown interface, and is compiled as such. By removing this you break compatibility with both MONO and the .NET framework, but keeping it makes the entire implementation remain reliant on a thin layer of the CLR framework implemented in C/C++. It could be that im just not seeing the obvious but if it is a problem, a solution should be found. :) [Less]
