Endless loop on ARM while printing backtrace with -Cpanic=abort

[TimNN]

This happens with LLVM 4.0, see #40123 (comment) for some more information.

Filing the issue now to have an issue number to reference.

cc #40123

[matt36]

I'm adding this comment here, because I can't comment on #40123

Thumb-2 is definitely an optional feature of ARMv6, and only became standard with ARMv7.

An example of an ARM core that is ARMv6 but doesn't support Thumb-2 would be the ARM1176 in the Raspberry Pi 1.

[TimNN]

(Note that this issue is unrelated to the Thumb 0 / 1 / 2 issue, at least it occurs independent of which version is used).

[infinity0]

The issue also happens on 1.17.0 armhf (armv7-unknown-linux-gnueabihf) when dynamically linking against Debian LLVM 3.9.1-10 with the fix for #41291 backported into it.

So it's probably something to do with (the lack of) Rust's LLVM patches rather than LLVM 4.0 itself. Here's the full list, compared with LLVM 3.9:

https://gist.github.com/infinity0/873566481db105fea47630da88e1b632

(Debian recently also applied 0032-Fix-computeKnownBits-for-ARMISD-CMOV.patch)

[infinity0]

I forgot to add, the issue goes away when I apply a146431, so I'm pretty sure it's the same issue.

[jeff-hiner]

Just ran into this issue today on a Raspberry Pi 3B+, running armhf on Rust stable 1.35.0.

This appears to be a side effect of how the compiler handles LR for divergent functions. As some background: LR, the link register, is used as the value of the program counter when returning from a function.

As I understand it, normally the compiler pushes LR onto the stack in the preamble of every function. If register pressure is high, the compiler can use LR for normal computation, but it must restore LR before branching into a new function in order to maintain stack integrity. But as an optimization the compiler does NOT have to restore the LR before branching into a divergent function-- this makes sense, because we've told the compiler that the function will never return, so there's no point in maintaining that LR on the stack. Normally this assumption is fine.

But in a Rust panic, the default handler calls into libunwind to read the stored LR and walk up the stack and determine what called what, and in which order. This is then used to print backtraces. If the trail of breadcrumbs was corrupted by upstream code, libunwind eats its own tail and you get infinite backtraces that look like: std::sys_common::backtrace::_print at src/libstd/sys_common/backtrace.rs:71

Somewhere in libcore or libstd there is a bit of panic handling code that's stomping on LR. And it's dependent on whether panics are compiled as unwind or abort.