GC on ARM64 based "kind of unix" system

[RalfKornmannEnvision]

I am sorry to bother again. After fixing some more minor issues and brush up my ARM64 assembler knowledge I was finally able to run a simple hello world on my ARM64 system without crashing. Doing things like writing to the log (the system doesn't have a text based console at all), Thread.Sleep, Environment.TickCount, printing the command line arguments etc works fine. But than I made the "mistake" to trigger the GC.

To make a long story short after some more debugging I noticed that the unwind of the stack does not work. The reason was pretty obvious. Libunwind doesn't have any information about the function were the stack walk should be started. I am aware that there are some parts missing for ARM64 targets that I need to fill but there is one question I was not able to answer so far. Does the GC only need unwind information for the managed code part? Or do I need to provide information for the C/C++ parts and even the dynamic libs of the OS? I am aware that libunwind can fetch these information by it's own. Unfortunately the function that it uses for this is not supported by the OS my system is using. I may be able to get the unwind sections from the runtime C/C++ code.

[jkotas]

Does the GC only need unwind information for the managed code part?

Correct.

[jkotas]

Unfortunately the function that it uses for this is not supported by the OS my system is using

We have a local copy of libunwind under https://github.com/dotnet/corert/tree/master/src/Native/libunwind. You should be able to modify as necessary to work for your OS.

[RalfKornmannEnvision]

Unfortunately the function that it uses for this is not supported by the OS my system is using

We have a local copy of libunwind under https://github.com/dotnet/corert/tree/master/src/Native/libunwind. You should be able to modify as necessary to work for your OS.

I have seen it when I setup the project to compile the runtime. The issue is somewhat more complicated. There is no API call at all to get the eh_frame or eh_frame_hdr section for a loaded module. There are only some limited functions that can be used to generate a human readable callstack but only for diagnostic. I am aware that one of these many limitations might be stopping me in the end to get it fully working. But these limitations are one of the main reasons why I am even trying as there is no way at all to get any JIT based implementation running. Independent of my success I think that at least some parts of my work should be usable for other ARM64 system and can be pushed back after some cleanup.

[MichalStrehovsky]

Might be worth looking into how C++ unwinds the stack on your OS (if there's a C++ compiler). The mechanism used for unwinding C++ exceptions might be usable for the GC and .NET exception handling too.

[RalfKornmannEnvision]

Might be worth looking into how C++ unwinds the stack on your OS (if there's a C++ compiler). The mechanism used for unwinding C++ exceptions might be usable for the GC and .NET exception handling too.

Yes, there is a C++ compiler. The toolchain is LLVM based and the executable files are ELF with eh_frame and eh_frame_hdr sections. I assume the even use the LLVM unwind to handle the c++ exceptions. Based on everything I can see there is nothing special here. The eh_frames just contains regular CFI data and the libunwind that is part of corert can parse them. The stack itself seems pretty much build up in the same way as ryujit does it. I can see functions from the ilcompiler and the c compiler there and jump to any of them. breakpoints and line stepping are working, too. The only thing that doesn't work right now are inspecting of variables. But as Debug.WriteLine is working I can somewhat handle this until I find a better solution.

The primary issue is that there is just no way to get the eh_frame data of the system modules and only an indirect to get it for your own executable. But based on jkotas I just need the unwind information for the managed code that is generated by the ilcompiler.

And the issue with that is that ryujit so far doesn't generate CFI frame information for ARM64. So this would be the starting point for me to get the CG working.

[RalfKornmannEnvision]

Looks like it's working now. Thanks for the help.