Array Support

[JoshuaWierenga]

Despite my efforts to improve array support so far, it is currently impossible to store a regular array directly in a static class/struct. As an example, in my current efforts to port System.DateTime I had these two arrays defined that caused the program to crash at runtime if used. I solved this by moving the arrays into the function I needed them for. This method, however, breaks somewhat if I need them for something else later on.

This has been the case for quite a while since I had the same problem here in my console class. Since it crashes at runtime, it has so far been impossible to diagnose. It might be possible to inspect the efi file to see if the method used to define the arrays is broken, however.

[KieranFoot]

You could try running in qemu and debug with gdb. Or try outputting to C++ instead of a full compilation and see if you can spot anything obvious in that code.

[KieranFoot]

As it is, I'm building a very similar project to yours so I'll take a look at it for you as a resolution benefits us both.

[JoshuaWierenga]

That is a good idea, I did figure out since I last updated this page that the bug here has nothing to do with arrays specifically as all static reference fields cause crashes at runtime. It terms of actual array support I did make a branch with the intention of adding everything from Array.cs and Array.CoreRT.cs but got stuck getting interface functions working. A proper debugging setup would be required to figure out why they doesn't work.

[JoshuaWierenga]

That work is in https://github.com/JoshuaWierenga/EfiSharp/tree/ArrayImprovements and https://github.com/JoshuaWierenga/EfiSharp/tree/InterfaceSupport.

[JoshuaWierenga]

From finally having something resembling a debugger setup I think I have identified the problem with static reference fields. Something is going wrong in https://github.com/dotnet/runtimelab/blob/fddede1/src/coreclr/nativeaot/Test.CoreLib/src/System/Runtime/CompilerServices/ClassConstructorRunner.cs#L35-L86, perhaps because it's the Test.CoreLib version. it just wasn't designed to handle this case?

"This is a simplistic placeholder implementation" suggests this might be the problem and if not then swapping it out is still a good idea since this corelib is growing and will encounter its limitations at some point.

[JoshuaWierenga]

Another option might be if RhpNewFast/Array is not allocating the right size.

[JoshuaWierenga]

Found another issue, this happens when assigning a new array to a static array field, might be windows specific though. Tried both LocalAlloc and GlobalAlloc with no change.

[JoshuaWierenga]

While messing around with the StartupCodeMain function I found a temporary fix which is to replace static reference fields with IntPtrs and then access with field = Unsafe.As<ActualType, IntPtr>(ref local) and local = Unsafe.As<IntPtr, ActualType>(ref field). I tried field = (IntPtr)Unsafe.AsPointer(ref local) and local = Unsafe.Read<ActualType>((void*)field) first but the reading line sometimes gives junk data back.