Of course, it's far from impossible, I'm just saying it wouldn't be a walk in the park. The backtrace handling would likely have to be fixed in the runtime (pro

Of course, it's far from impossible, I'm just saying it wouldn't be a walk in the park. The backtrace handling would likely have to be fixed in the runtime (probably enabled with a -Zbuild-std option) rather than being user-configurable, since there's hardly any way to start documenting which standard library features are async-signal-safe. But even then, doing it in a POSIXly-correct way is hard: already, the standard library unsoundly uses thread-local storage in the SIGSEGV handler (not async-signal-safe per POSIX) to verify that it came from hitting the thread's guard page. backtrace-rs mostly delegates the hard work of unwinding to _Unwind_Backtrace on Unix-like systems, but it unconditionally uses a global mutex (not async-signal-safe) to protect backtrace operations on all platforms, perhaps because of dbghelp.dll on Windows. I think _Unwind_Backtrace is async-signal-safe (since libunwind claims to be async-signal-safe, and it supposedly uses _Unwind_Backtrace), so it could probably be done. But someone would have to put a fair bit of work into both the backtrace-rs API and the SIGSEGV handler in std, especially since _Unwind_Backtrace apparently needs additional incantations to work properly from a signal handler.