[llvm-dev] LLVM libunwind stack usage

[Craig, Ben via llvm-dev]

Are you suggesting that the size of the data arrays in unw_context_t and 
unw_cursor_t be made smaller?  If so, then I am concerned that this 
might break binary compatibility for shared-object builds of libunwind 
(assuming that's a thing).  Both of those structures are mentioned and 
used in the libunwind.h header.

If binary compatibility turns out to be a non-issue, then I'm fine with 
making those data array sizes platform dependent.  I would want there to 
be static_asserts in various locations to make sure that the size of the 
Registers_xxx classes stays in sync with the data arrays though.

I don't know if you can get away with just saving the callee spilled 
registers or not.

On 1/19/2016 4:09 PM, Ed Maste via llvm-dev wrote:
> 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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project