[llvm-dev] LLVM libunwind stack usage

[Ed Maste via llvm-dev]

I've started the process of bringing LLVM's libunwind into the FreeBSD
base system[1]. As part of that process we've tested building the
approximately 25,000 third party software packages in the FreeBSD
ports collection against a modified FreeBSD with libunwind
included[2]. Of course, I wouldn't expect much in the way of build
failures -- I'd expect any issues to be largely run-time ones.

We did observe one build failure on x86-64 though, in a software
package that builds and runs exception-using tool at build time. The
failure turned out to be a stack overflow[3] during the forced-unwind
cleanup of a thread with a minimum-sized (4K) stack.

LLVM libunwind has allows for 120 saved registers, common across all
architectures (kMaxRegisterNumber in src/DwarfParser.hpp). In contrast
the GCC unwinder has a target-dependent maximum; on x86-64 it's 18.
LLVM libunwind requires 1920 bytes for register storage, vs. 288 for
the GCC unwinder.

Is it reasonable to change LLVM libunwind to use an approach similar
to GCC's unwinder, and have a target-specific maximum DWARF register
number? X86 does have DWARF register numbers above the 18 that GCC
accommodates, but they're not going to be useful in the unwinder
anyhow.

[1] https://svnweb.freebsd.org/changeset/base/293450
[2] https://bugs.freebsd.org/206039
[3] https://bugs.freebsd.org/206384