Building MOOS a native OS written in C# with BFLAT throws `'Expected type System.Runtime.InteropServices.Marshal' not found` in module 'MOOS' about bflat HOT 24 OPEN

The format of the table changed like this: dotnet/runtime@1771d63

Bflat 0.0.8 would probably still work. Anything newer had that change.

from bflat.

Finally, I wrote a text to introduce how to build MOOS with BFlat as a summary:
https://github.com/xiaoyuvax/MOOS/blob/master/MOOS.bflat.md

from bflat.

That sounds like missing -i parameters. Moos probably sets it as directpinvoke.

from bflat.

Can u be more specific?
by explaining the -i <library|library!function> option
or at least in my case, what should i do?

do u mean like for each:

       [DllImport("WriteLine")]
        public static extern void WriteLine();

        [DllImport("Allocate")]
        public static extern nint Allocate(ulong size);

        [DllImport("Free")]
        public static extern ulong Free(nint ptr);

add -i options like below?

-i MOOS!WriteLine
-i MOOS!Allocate
-i MOOS!Free

Can't these be universally set?

I tried -i MOOS, seems still not working.

from bflat.

No, this would be -i WriteLine -i Allocate, etc. The way DllImports are set up in MOOS is super weird. Normally the thing in the DllImport string is the name of the DLL. Since you have a fork, you migth as well change the DllImport declarations to be DllImport("*") (some are already like that). Those work out of the box.

from bflat.

change the DllImport declarations to be DllImport("*") doesn't work, the compiler throws weird error.

I checked with the code, such [DllImport("SayHello")] is used as a symbol for the interrrupt handlers written in masm to identify the name of the function for handling system api call, as shown below:

as for the -i option, one by one?!! it's really heartwarming ~~~
ps. i'd really expect an one off switch-on for the entire module in the next version of bflat.

from bflat.

Ah, I see. Now I understand why the DllImports are so weird. Adding -i is not the solution. MOOS expects that these will be lazy resolved.

This is failing because the support for ansi string marshalling is not present in MOOS corelib. MOOS is compiled using an ancient version of NativeAOT. You can find the current version of AnsiStringMarshaller class (that is in the failing callstack) here:

https://github.com/dotnet/runtime/blob/99aa25fee09a3a66fb698720a234eb3d7770ca1a/src/coreclr/tools/Common/TypeSystem/Interop/IL/Marshaller.cs#L1583

You need to apply dotnet/runtime@e22c63e to MOOS corelib. You'll see that MOOS has the "InteropHelpers.CoTaskMemFree" in corelib, but doesn't have "Marshal.FreeCoTaskMem". The fix is to create it.

from bflat.

See if i understood correctly:
CoTaskMemFree() has been removed in the new version of compiler, so i have to amend its implementation for bflat to compile, right?
but in the source of nativeAot, this method is actually implemented through ole32.dll (for windows), what can i do in MOOS then?

so, i just added a Marshal class with a sole FreeCoTaskMem() method and the compiling seems done.

but the linker throws some errors:

- Executing building script: bflat build @build.rsp...
ILC: Method '[MOOS]Internal.Runtime.CompilerServices.Unsafe.As<__Canon,native int>(__Canon&)' will always throw because: Invalid IL or CLR metadata in 'IntPtr ByRef Internal.Runtime.CompilerServices.Unsafe.As(System.__Canon ByRef)'
ILC: Method '[MOOS]Internal.Runtime.CompilerServices.Unsafe.As<native int,__Canon>(native int&)' will always throw because: Invalid IL or CLR metadata in 'System.__Canon ByRef Internal.Runtime.CompilerServices.Unsafe.As(IntPtr ByRef)'
ILC: Method '[MOOS]Internal.Runtime.CompilerServices.Unsafe.SizeOf<GDTEntry>()' will always throw because: Invalid IL or CLR metadata in 'Int32 Internal.Runtime.CompilerServices.Unsafe.SizeOf()'
ILC: Method '[MOOS]Internal.Runtime.CompilerServices.Unsafe.SizeOf<TSS>()' will always throw because: Invalid IL or CLR metadata in 'Int32 Internal.Runtime.CompilerServices.Unsafe.SizeOf()'
ILC: Method '[MOOS]Internal.Runtime.CompilerServices.Unsafe.AsPointer<IDTEntry>(IDTEntry&)' will always throw because: Invalid IL or CLR metadata in 'Void* Internal.Runtime.CompilerServices.Unsafe.AsPointer(IDTEntry ByRef)'
ILC: Method '[MOOS]Internal.Runtime.CompilerServices.Unsafe.Add<char>(char&,int32)' will always throw because: Invalid IL or CLR metadata in 'Char ByRef Internal.Runtime.CompilerServices.Unsafe.Add(Char ByRef, Int32)'
ILC: Method '[MOOS]Internal.Runtime.CompilerServices.Unsafe.As<bool,uint64>(bool&)' will always throw because: Invalid IL or CLR metadata in 'UInt64 ByRef Internal.Runtime.CompilerServices.Unsafe.As(Boolean ByRef)'
ILC: Method '[MOOS]Internal.Runtime.CompilerServices.Unsafe.As<__Canon>(object)' will always throw because: Invalid IL or CLR metadata in 'System.__Canon Internal.Runtime.CompilerServices.Unsafe.As(System.Object)'
ILC: Method '[MOOS]Internal.Runtime.CompilerServices.Unsafe.As<__Canon,__Canon>(__Canon&)' will always throw because: Invalid IL or CLR metadata in 'System.__Canon ByRef Internal.Runtime.CompilerServices.Unsafe.As(System.__Canon ByRef)'
lld: error: could not open 'MSVCRTD.lib': No such file or directory
lld: error: could not open 'OLDNAMES.lib': No such file or directory
lld: error: duplicate symbol: free in MOOS.obj and in api-ms-win-crt-heap-l1-1-0.dll
lld: error: duplicate symbol: malloc in MOOS.obj and in api-ms-win-crt-heap-l1-1-0.dll
lld: error: duplicate symbol: realloc in MOOS.obj and in api-ms-win-crt-heap-l1-1-0.dll
lld: error: duplicate symbol: memcpy in MOOS.obj and in shcrt.lib(nocrt.cpp.obj)
lld: error: duplicate symbol: memset in MOOS.obj and in shcrt.lib(nocrt.cpp.obj)
Compiler exit code:1

from bflat.

CoTaskMemFree is an empty method in MOOS, so I would implement FreeCoTaskMem as an empty method too.

The Unsafe class moved from Internal.Runtime.CompilerServices to System.Runtime.CompilerServices, so you should also update MOOS to get rid of the warnings.

Adding --libc none to bflat build might get rid of the lld errors.

from bflat.

the duplicated symbols are eliminated by adding --libc none, only the last two errors left:

lld: error: could not open 'MSVCRTD.lib': No such file or directory
lld: error: could not open 'OLDNAMES.lib': No such file or directory

from bflat.

I solve it by copying these two files from vc15 to building path. now it's done! ;)))
don't know if the binary would run... go on building the system image.

from bflat.

Final outcome report:
The MOOS.exe built by bflat is much smaller than that compiled by ILCompiler and is not runnable after being packed to system image.
without the kernel.map file due to lld.exe not supporting /map: option, i can't compare the compiling result to see if it's right.

from bflat.

If you compile with -c, you can use link.exe on the generated obj file and get a map file that way

from bflat.

ah, yes, i did have thought of using MSVC Linker, after i found out that lld.exe in bflat path looks actually like MSVC linker.

I checked the map, and found the most important init methods such as Entry() , KMain() were all missing in the exe built by bflat. No idea why.

 [RuntimeExport("Entry")]
        public static void Entry(MultibootInfo* Info, IntPtr Modules, IntPtr Trampoline)
        { ...

  [RuntimeExport("KMain")]
    static void KMain()
    { ...

Instead, i used ObjectDump to have extracted the map for MOOS.obj, where i can see the symbols for Entry() and KMain(), don't know why they disappear after linking.

from bflat.

Does moos pass a /def parameter to link.exe to make it exported?

from bflat.

linker args do not include /def in moos.csproj
and i don't see any .def files in the project path

i am not sure if linker should know any of these settings in .csproj file:
especially the EntryPointSymbol must be specified somehow?
Would IlcSystemModule and RuntimeAssembly mean something to linker?
and there is also a CustomizeReferences section, it is also suspected to do something with the output? ...

<IlcSystemModule>MOOS</IlcSystemModule>
<EntryPointSymbol>Entry</EntryPointSymbol>
<LinkerSubsystem>NATIVE</LinkerSubsystem>
<IlcOptimizationPreference>Size</IlcOptimizationPreference>
...

<!--CustomizeReferences-->
	<Target Name="CustomizeReferences" BeforeTargets="BeforeCompile" AfterTargets="FindReferenceAssembliesForReferences">
		<ItemGroup>
			<ReferencePathWithRefAssemblies Remove="@(ReferencePathWithRefAssemblies)" Condition="%(Filename) != 'Corlib'" />
			<ReferencePath Remove="@(ReferencePath)" />
		</ItemGroup>
	</Target>

...
	<RuntimeAssembly Include="MOOS"></RuntimeAssembly>

from bflat.

update:
Yes, after adding /Entry:Entry to the linker args, now the exe file's size grows larger, and the Entry symbol appears.
the exe size is 376kb while moos original compiled is 426kb, still some significant difference.

from bflat.

update FINALLY！:
i used -x option upon MSBuild to have got and applied the exact args of the linker, now the exe image generated from bflat + linker.exe is exact the same size with that generated by MSBuild+ILCompiler, now the OS is running.

the args that finally work:

"C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.35.32215\bin\Hostx64\x64\link.exe" MOOS.obj /out:"MOOS.exe" ^
d:\repos\moos\x64\Debug\Doom.lib ^
d:\repos\moos\x64\Debug\LibC.lib ^
d:\repos\moos\x64\Debug\NativeLib.lib ^
/LIBPATH:"C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.35.32215\lib\x64" ^
/LIBPATH:"C:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\lib\um\x64" ^
/LIBPATH:"C:\Program Files (x86)\Windows Kits\10\lib\10.0.22621.0\ucrt\x64" ^
/LIBPATH:"C:\Program Files (x86)\Windows Kits\10\\lib\10.0.22621.0\\um\x64" ^
D:\Repos\MOOS\MOOS\obj\Debug\net7.0\win-x64\native\MOOS.res ^
/fixed /base:0x10000000 /map:Kernel.map /NOLOGO /MANIFEST:NO /DEBUG /INCREMENTAL:NO /SUBSYSTEM:NATIVE /ENTRY:Entry

i also tested lld.exe comes with bflat with following args:

d:\bflat\bin\lld.exe -flavor link MOOS.obj /out:"MOOS.exe" ^
d:\repos\moos\x64\Debug\Doom.lib ^
d:\repos\moos\x64\Debug\LibC.lib ^
d:\repos\moos\x64\Debug\NativeLib.lib ^
/LIBPATH:"C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.35.32215\lib\x64" ^
/LIBPATH:"C:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\lib\um\x64" ^
/LIBPATH:"C:\Program Files (x86)\Windows Kits\10\lib\10.0.22621.0\ucrt\x64" ^
/LIBPATH:"C:\Program Files (x86)\Windows Kits\10\\lib\10.0.22621.0\\um\x64" ^
D:\Repos\MOOS\MOOS\obj\Debug\net7.0\win-x64\native\MOOS.res ^
/fixed /base:0x10000000 /NOLOGO /MANIFEST:NO /DEBUG /INCREMENTAL:NO /SUBSYSTEM:NATIVE /ENTRY:Entry 

it still throws the following errors relatied to lib path:"C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.35.32215\lib\x64" but is not seen with linker.exe

lld: error: undefined symbol: __guard_eh_cont_table
>>> referenced by MSVCRTD.lib(loadcfg.obj):(_load_config_used)

lld: error: undefined symbol: __guard_eh_cont_count
>>> referenced by MSVCRTD.lib(loadcfg.obj):(_load_config_used)

Summary:
now i'd expect bflat solve following issues as to make the toolchain from BFlatA -> BFlat -> lld to work fluently on building such a project like MOOS:

1. correctly pass paths strings with spaces to lld, where quotes being correctly passed to the linker, now the chain is stuck here!
2. solve the "undefined symbol" errors lld throws, which is not seen with linker.exe.
3. lld.exe should support /map: option as linker.exe do.
4. Allow fully controlling args passing to the linker, bflat seemingly adds certain assumed default args which is not necessary in some case.

from bflat.

Why can't i find this res file with BFlat after compiling? seems a must for MOOS, seen in both moos.ilc.rsp and linker.rsp, even no much content inside. @MichalStrehovsky
D:\Repos\MOOS\MOOS\obj\Debug\net7.0\win-x64\native\MOOS.res

from bflat.

The rest file contains the Win32 resources of the module. It will probably be Win32 version resource. Bflat doesn't currently generate it.

from bflat.

So sad and weird, can't reproduce runnable image of MOOS any more after last success, even the image is successfully built. No idea of what's wrong.

from bflat.

Seems related to the customized Internal.Runtime.CompilerHelpers.StartupCodeHelpers.InitializeModules() of MOOS (if compiled with bflat, no problem with MSBuild + ILCompiler) , which calls its method:
private static unsafe void InitializeStatics(IntPtr rgnStart, IntPtr rgnEnd) as shown below and error occurs at the marked line. It seems that *pBlock cannot be accessed at that address (or may be out of memory range).

Corresponding COM output:

from bflat.

Bingo! thanks for your link!
I simply copied the ReadRelPtr32() method and applied it on the problematic pointers, everything come back to normal. Now MOOS runs smoothly. Bflat is proved to be an alternative and even prefered compiler for building such a project like MOOS.

from bflat.

Finally, I wrote a text to introduce how to build MOOS with BFlat as a summary: https://github.com/xiaoyuvax/MOOS/blob/master/MOOS.bflat.md

Very cool! Thanks for sharing!

from bflat.