[Support][RISCV] Disable use of backtrace() for RISC-V backtraces

[luismarques]

Summary

AFAIK backtrace is fundamentally broken for RISC-V, even if you compile everything with frame pointers. Even if it could be fixed, right now it's broken in ~all systems so I think it's best to disable it for RISC-V.

[luismarques]

llvm/lib/Support/Unix/Signals.inc

566

The "Linux" in the comment will be removed before committing.

[arichardson]

I am almost certain backtrace() does work on FreeBSD, so there should be a __linux__ check as well.
The comment says it only exists on glibc systems, but on FreeBSD libexecinfo provides this functionality.

[reames]

Can you give a bit more context on *why* backtrace is broken? And on which systems you've observed this? This is the first time I'm hearing this.

[luismarques]

In D144174#4141913, @reames wrote:

Can you give a bit more context on *why* backtrace is broken? And on which systems you've observed this? This is the first time I'm hearing this.

https://forums.sifive.com/t/how-to-get-backtrace-in-rtos-based-on-risc-v-64/5643/2:

On RISC-V, the only reliable way to backtrace is to use the EH unwind info. I don’t think that the glibc backtrace() function will work.

I've observed this in Linux glibc RV64 systems (Fedora and Ubuntu).

[kito-cheng]

RISC-V GCC has added -fasynchronous-unwind-tables to the default option for linux, maybe we should do that on clang side? this should able improve the situation.

https://github.com/gcc-mirror/gcc/commit/3cd08f7168c196d7a481b9ed9f4289fd1f14eea8

[kito-cheng]

Patch posted: https://reviews.llvm.org/D145164

[kito-cheng]

In D144174#4134399, @arichardson wrote:

I am almost certain backtrace() does work on FreeBSD, so there should be a __linux__ check as well.
The comment says it only exists on glibc systems, but on FreeBSD libexecinfo provides this functionality.

Maybe it's the reason why FreeBSD work fine:

ToolChain::UnwindTableLevel
FreeBSD::getDefaultUnwindTableLevel(const ArgList &Args) const {
  return UnwindTableLevel::Asynchronous;
}

https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/ToolChains/FreeBSD.cpp#L489

[luismarques]

In D144174#4164652, @kito-cheng wrote:

RISC-V GCC has added -fasynchronous-unwind-tables to the default option for linux, maybe we should do that on clang side? this should able improve the situation.

Maybe we should do that anyway, but AFAICT it would not improve the GNU backtrace situation. See also my D144178, which I guess will be less needed if your D145164 gets merged.

[luismarques]

In D144174#4164725, @luismarques wrote:

AFAICT it would not improve the GNU backtrace situation.

Sorry, I was speaking from memory and it had been a while since I looked at this. I went back to check my notes/tests and -fasynchronous-unwind-tables does help for backtrace.

llvm/lib/Support/Unix/Signals.inc

 // user has an indication of why and where we died.
 //
 // On glibc systems we have the 'backtrace' function, which works nicely, but
 // doesn't demangle symbols.
 void llvm::sys::PrintStackTrace(raw_ostream &OS, int Depth) {
 #if ENABLE_BACKTRACES
   static void *StackTrace[256];
   int depth = 0;
-#if defined(HAVE_BACKTRACE)
+#if defined(HAVE_BACKTRACE) && !defined(__riscv)
   // Use backtrace() to output a backtrace on Linux systems with glibc.
+  // Don't use it on RISC-V Linux because it's highly unlikely to work but it
+  // may return 1 or 2 entries, preventing the retry with _Unwind_Backtrace
+  // below.
   if (!depth)
     depth = backtrace(StackTrace, static_cast<int>(std::size(StackTrace)));
 #endif
 #if defined(HAVE__UNWIND_BACKTRACE)
   // Try _Unwind_Backtrace() if backtrace() failed.
   if (!depth)
     depth =
         unwindBacktrace(StackTrace, static_cast<int>(std::size(StackTrace)));