MichalStrehovsky
commented
1 year ago That sounds like missing -i parameters. Moos probably sets it as directpinvoke.
Open xiaoyuvax opened 1 year ago
MichalStrehovsky
commented
1 year ago That sounds like missing -i parameters. Moos probably sets it as directpinvoke.
xiaoyuvax
commented
1 year ago 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!FreeCan't these be universally set?
I tried -i MOOS, seems still not working.
MichalStrehovsky
commented
1 year ago 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.
xiaoyuvax
commented
1 year ago 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.
MichalStrehovsky
commented
1 year ago 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:
You need to apply https://github.com/dotnet/runtime/commit/e22c63e2fa78931c6a4802e555370324c34475bd 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.
xiaoyuvax
commented
1 year ago 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:1CoTaskMemFree 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.
xiaoyuvax
commented
1 year ago 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 directoryI 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.
xiaoyuvax
commented
1 year ago 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.
MichalStrehovsky
commented
1 year ago If you compile with -c, you can use link.exe on the generated obj file and get a map file that way
xiaoyuvax
commented
1 year ago 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.
MichalStrehovsky
commented
1 year ago Does moos pass a /def parameter to link.exe to make it exported?
xiaoyuvax
commented
1 year ago 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>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.
xiaoyuvax
commented
1 year ago 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:Entryi 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.
xiaoyuvax
commented
1 year ago 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
MichalStrehovsky
commented
1 year ago The rest file contains the Win32 resources of the module. It will probably be Win32 version resource. Bflat doesn't currently generate it.
xiaoyuvax
commented
1 year ago 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.
xiaoyuvax
commented
1 year ago 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:
MichalStrehovsky
commented
1 year ago The format of the table changed like this: https://github.com/dotnet/runtime/commit/1771d63827387b49dcd8c33b95f1512f4f11e368
Bflat 0.0.8 would probably still work. Anything newer had that change.
xiaoyuvax
commented
1 year ago 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.
xiaoyuvax
commented
1 year ago 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
MichalStrehovsky
commented
1 year ago 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!
Building MOOS - a native OS written in C# with BFLAT throws following error:
Obviously, this is because Marshal.cs is absent from the trimmed custom Corlib framework in MOOS project (as u can see from the RSP file below), specified by
<IlcSystemModule>MOOS</IlcSystemModule>in the csproj file. However, MOOS can be successfully compiled with MSBuild and then be compiled to native binary through ILCompiler and run on bare metal. I am trying to compile MOOS directly from source to native binary by BFLAT, but here comes the Marshal.cs problem, any hint to solve it?RSP file contents (generated by BFlatA ):