stackwalk: fix heuristic termination (#57801)

When getting stacktraces on non-X86 platforms, the first frame may not
have been set up yet, incorrectly triggering this bad-frame detection
logic. This should fix the issue of async unwind failing after only
getting 2 frames, if the first frame happens to land in the function
header. This is not normally an issue on X86 or non-signals, but also
causes no expected issues to be the same logic there too.

Fix #52334

After (on arm64-apple-darwin24.3.0):
```
julia> f(1)
Warning: detected a stack overflow; program state may be corrupted, so further execution might be unreliable.
ERROR: StackOverflowError:
Stacktrace:
     [1] f(x::Int64)
       @ Main ./REPL[3]:1
     [2] g(x::Int64)
       @ Main ./REPL[4]:1
--- the above 2 lines are repeated 39990 more times ---
 [79983] f(x::Int64)
       @ Main ./REPL[3]:1
```

n.b. This will not fix and is not related to any issues where profiling
gets only a single stack frame during profiling of syscalls on Apple
AArch64. This fix is specific to the bug where it gets exactly 2 frames.

(cherry picked from commit f82917a)

Author: vtjnash

src/stackwalk.c

@@ -98,9 +98,13 @@ static int jl_unw_stepn(bt_cursor_t *cursor, jl_bt_element_t *bt_data, size_t *b
             }
             uintptr_t oldsp = thesp;
             have_more_frames = jl_unw_step(cursor, from_signal_handler, &return_ip, &thesp);
-            if (oldsp >= thesp && !jl_running_under_rr(0)) {
-                // The stack pointer is clearly bad, as it must grow downwards.
+            if ((n < 2 ? oldsp > thesp : oldsp >= thesp) && !jl_running_under_rr(0)) {
+                // The stack pointer is clearly bad, as it must grow downwards,
                 // But sometimes the external unwinder doesn't check that.
+                // Except for n==0 when there is no oldsp and n==1 on all platforms but i686/x86_64.
+                // (on x86, the platform first pushes the new stack frame, then does the
+                // call, on almost all other platforms, the platform first does the call,
+                // then the user pushes the link register to the frame).
                 have_more_frames = 0;
             }
             if (return_ip == 0) {
@@ -132,11 +136,11 @@ static int jl_unw_stepn(bt_cursor_t *cursor, jl_bt_element_t *bt_data, size_t *b
             // * The way that libunwind handles it in `unw_get_proc_name`:
             //   https://lists.nongnu.org/archive/html/libunwind-devel/2014-06/msg00025.html
             uintptr_t call_ip = return_ip;
+            #if defined(_CPU_ARM_)
             // ARM instruction pointer encoding uses the low bit as a flag for
             // thumb mode, which must be cleared before further use. (Note not
             // needed for ARM AArch64.) See
             // https://github.com/libunwind/libunwind/pull/131
-            #ifdef _CPU_ARM_
             call_ip &= ~(uintptr_t)0x1;
             #endif
             // Now there's two main cases to adjust for: