nativeaot for rtos

[snikeguo]

I am now continuing to work on the porting of nativeaot+rtos:

I'm encountering an infinite loop in the stack unwinding logic when calling Environment.StackTrace in a minimal C# program. After resolving TLS-related issues (--enable-tls confirmed working), the stack frame iterator enters an infinite loop during stack unwinding.

main()
{
    var stacktrace = Environment.StackTrace;
}

Observed Behavior:​​
The call stack enters an infinite loop in StackFrameIterator::Next() because IsValid() persistently returns true. When examining the ControlPC values during unwinding, I observe the following pattern:

1.S_P_CoreLib_System_Runtime_RuntimeExports__RhGetCurrentThreadStackTrace
2.S_P_CoreLib_System_Diagnostics_StackTrace__InitializeForCurrentThread
3.S_P_CoreLib_System_Diagnostics_StackTrace___ctor_0
4.S_P_CoreLib_System_Environment__get_StackTrace
5.Helloworld_Helloworld_Program__Main
6.__managed__Main
7.__managed__Main (repeated)
8.__managed__Main (repeated)

Problem Location:​​
The infinite loop occurs in RhpCalculateStackTraceWorker():

RhpCalculateStackTraceWorker（）
{
    while (frameIter.Next()){ ....}
}

[jkotas]

This likely means that the unwind data are wrong. You need to step through the unwinder to figure it out.

[jkotas]

It may work better if you open an issue or discussion about your rtos port and keep asking these questions on the same issue instead of opening new issues.

[snikeguo]

can I understand it this way:In the Thread::Construct() function, the m_pTransitionFrame and m_pDeferredTransitionFrame are set to TOP_OF_STACK_MARKER, which serves as the termination marker for stack unwinding. When stack unwinding reaches the end, the following code in UnixNativeCodeManager::UnwindStackFrame will be executed:
ppPreviousTransitionFrame = (PInvokeTransitionFrame*)(basePointer + slot);
At this point, the value should be 0xFFFFFFFF(TOP_OF_STACK_MARKER)
We are using the R7 register FP in thumb2, not R11. Could this be the problem?
I don’t know what slot means in (PInvokeTransitionFrame**)(basePointer + slot).

[jkotas]

We are using the R7 register FP in thumb2

Yes, it can be a problem. This register must be change in number of places, including the JIT. You might have missed some of them.

[snikeguo]

We are using the R7 register FP in thumb2

Yes, it can be a problem. This register must be change in number of places, including the JIT. You might have missed some of them.

Suppose I compile a nativeAOT runtime (including the Bootstrap project) on Linux, targeting the Thumb2 instruction set and running in a Linux environment. Does this mean there will be issues？since GCC uses R7 as the frame pointer instead of R11

[jkotas]

C/C++ code and the native AOT runtime do not have to use the same FP register.