Hi,

                 We’re using MUSL cross-compilation toolchains to build fully statically linked binaries, targeting x86_64, aarch64, and armel. (Which allows us to work around some issues with glibc incompatibilities)

                 If we connect GDB to our process and get a backtrace, we get very little.  i.e.:

__syscall_cp_c (Unknown Source:0)

__timedwait_cp (Unknown Source:0)

[Unknown/Just-In-Time compiled code] (Unknown Source:0)

Or:

__stdio_read (Unknown Source:0)

[Unknown/Just-In-Time compiled code] (Unknown Source:0)

                 We’d really like to get the rest of these stacks to investigate issues such as deadlocks, for example (among several other reasons, such as our own crash reporting handler).

                 I found related info on StackOverflow, such as: debugging - Why does gdb backtrace show only one frame when catching syscall? - Stack Overflow

                 And: c - Stack frame NULL in backtrace log - Stack Overflow

                 My hypothesis is that we’re calling into code that does not provide the stack unwind descriptors needed by GDB.  The first of the above links refers specifically to MUSL and patching it (but for MIPS).

                 I’ve tried building a fresh MUSL (1.2.4) GCC (13.2.0) toolchain, and the issue persists with a binary built with it.

                 Can someone explain what we’re running into here, and whether there is a potential solution (even if we may have to contribute it ourselves)?

Thanks!,

• Colen