mosa Work Item Rss Feed

Created Issue: mosacl Uses Wrong .NET Framework Folder On Win64 When mosacl Executes As AnyCpu

illuminus86 — Sat, 29 Aug 2009 00:52:42 GMT

If mosacl can't find an mscorlib in the current folder, it checks a number of paths including the current Framework folder which is the Framework64 folder when mosacl is running in x64 mode. mosacl compiles code incorrectly when using Framework64 mscorlib for reference purposes - and it is arguable both that we shouldn't be using PE32+ assemblies for 32-bit targetted compiles, and that we shouldn't be using the .NET mscorlib for reference anyway.

The assembly loader's search paths need to be thought out a bit more and changed.

Closed Issue: mosacl Fails To Resolve mscorlib On Win64 When mosacl Executes As AnyCpu

illuminus86 — Sat, 29 Aug 2009 00:45:19 GMT

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.
Comments:

I'm closing this issue in lieu of a more concise one worded to drive this home.

Commented Issue: mosacl Fails To Resolve mscorlib On Win64 When mosacl Executes As AnyCpu

illuminus86 — Sat, 29 Aug 2009 00:42:52 GMT

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.

Commented Issue: mosacl Fails To Resolve mscorlib On Win64 When mosacl Executes As AnyCpu

illuminus86 — Tue, 25 Aug 2009 12:29:55 GMT

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.

Commented Issue: mosacl Fails To Resolve mscorlib On Win64 When mosacl Executes As AnyCpu

moitoius — Mon, 24 Aug 2009 10:00:35 GMT

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.

Commented Issue: mosacl Fails To Resolve mscorlib On Win64 When mosacl Executes As AnyCpu

illuminus86 — Sun, 23 Aug 2009 03:13:06 GMT

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!

Closed Issue: Multiboot0695AssemblyStage Incorrectly Throws LinkerException

illuminus86 — Sat, 22 Aug 2009 04:03:39 GMT

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 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.

Created Issue: Multiboot0695AssemblyStage Incorrectly Throws LinkerException

illuminus86 — Fri, 21 Aug 2009 18:29:46 GMT

Commented Issue: mosacl Fails To Resolve mscorlib On Win64 When mosacl Executes As AnyCpu

54616E6E6572 — Fri, 21 Aug 2009 16:25:25 GMT

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.

Created Issue: mosacl Fails On Win64 When mosacl Input Is Built As AnyCpu

illuminus86 — Fri, 21 Aug 2009 16:04:01 GMT

Closed Task: PlugGen - Group Output Members Into Regions

illuminus86 — Wed, 05 Aug 2009 13:04:15 GMT

Group output members into region to make stubs easier to navigate through
Comments:

No longer valid

Closed Issue: PlugGen - Remove '&' From Ref/Out Parameter Outputs

illuminus86 — Wed, 05 Aug 2009 13:04:14 GMT

Right now, ref/out parameter types are outputting with the ampersand character appended. This is redundant to the ref/out keywords.
Comments:

No longer valid

Closed Task: PlugGen - Fill In Outputted Constant Field Values

illuminus86 — Wed, 05 Aug 2009 13:04:13 GMT

Outputted constant values need to be assigned during output generation as the constants need to exactly match their counterparts from the plugged type. The AOT/JIT will not be able to map inverse plug overrides on these "fields" because constants are probably inlined when an assembly is compiled into IL.

This needs to be done right because it can cause major headaches.

Difficulty arises because Mono.Cecil loads constant data as a byte array (as represented in IL), which needs to be re-expressed as a CodeDOM primitive for the PlugGen emission process. Normal references to original constant values in the plugged assembly is not always possible due to the usage of constant fields as private/protected members.
Comments:

No longer valid

Closed Issue: PlugGen - References To Generic Classes Do Not Output Fully

illuminus86 — Wed, 05 Aug 2009 13:04:12 GMT

There is an issue where references to generic interfaces (in a class's derived types, or in a explicit interface implementer of a method), where the generic parameters should be inferred from the loaded metadata and filled into the output code. This is a bug manifestation, as it is meant to be handled by existing code.
Comments:

No longer valid

Closed Feature: Implement Interface to Multiboot Information

tgiphil — Mon, 27 Jul 2009 01:37:19 GMT

Provide an static class to read the multiboot information structure.
Comments:

Closed Feature: Create a basic block ordering stage

tgiphil — Mon, 27 Jul 2009 01:33:13 GMT

The responsibility of a block ordering stage is to linearize the control flow in order to remove jumps inside a method. The optimal order is determined by removing any unneeded backwards jumps and eliminating forward jumps. To achieve this small blocks may need to be duplicated.

If this stage is introduced the register allocators and all other following stages must be changed to use this block order for processing as it represents the ideal flow of code.
Comments:

Closed Issue: Incorrect x86 variable offset

tgiphil — Sat, 04 Apr 2009 14:59:51 GMT

The compiler does not generate the correct x86 binary for the following method:

public unsafe static void WriteChar(byte c, byte color, byte* address)
{
    byte* address2 = address + 1;
    *address = c;
    *address2 = color;    // this is the problem statement
}

The IL generated for this method is:

.method public hidebysig static void WriteChar(uint8 c, uint8 color, uint8* address) cil managed
{
// Code size       13 (0xd)
.maxstack 2
.locals init ([0] uint8* address2)
IL_0000: nop
IL_0001: ldarg.2
IL_0002: ldc.i4.1
IL_0003: conv.i
IL_0004: add
IL_0005: stloc.0

IL_0006: ldarg.2
IL_0007: ldarg.0
IL_0008: stind.i1

IL_0009: ldloc.0
IL_000a: ldarg.1
IL_000b: stind.i1

IL_000c: ret
} // end of method Boot::WriteChar

And finally here's the disassemble code :

.text:00402EC1                 mov     [ebp+var_14], 1
.text:00402ECB                 mov     eax, [ebp+arg_8]
.text:00402ED1                 add     eax, [ebp+var_14]
.text:00402ED7                 mov     [ebp+var_10], eax

.text:00402EDD                 mov     eax, [ebp+arg_8]
.text:00402EE3                 mov     dl, [ebp+arg_0]
.text:00402EE9                 mov     [eax+0], dl

.text:00402EEF                 mov     eax, [ebp+var_C] ; should be mov eax, [ebp+var_10] ???
.text:00402EF5                 mov     dl, [ebp+arg_4]
.text:00402EFB                 mov     [eax+0], dl

The offset should be var_10 (and not var_C) in my opinion.

Any suggestions on how to fix this?
Comments: This is caused by a problem with SSA and not a variable offset.

Closing this case.

Closed Issue: RTL8139

tgiphil — Sat, 04 Apr 2009 14:21:16 GMT

The file Mosa/DeviceDrivers/PCI/NetworkCard/RTL8139.cs creates a class Mosa.DeviceDrivers.PCI.VideoCard.RTL8139.

The class should have the following namespace instead: Mosa.DeviceDrivers.PCI.NetworkCard.RTL8139
Comments: TRL8139 has been removed.

Commented Issue: Incorrect x86 variable offset

tgiphil — Sat, 04 Apr 2009 14:19:25 GMT

Seems to be an SSA problem and not an alignment problem.

Created Task: PlugGen - Fill In Outputted Constant Field Values

illuminus86 — Tue, 31 Mar 2009 05:26:07 GMT