Summary: | llvm libunwind requires larger stack than old unwinder (segfault while building lang/polyml) | ||
---|---|---|---|
Product: | Base System | Reporter: | Ed Maste <emaste> |
Component: | misc | Assignee: | Ed Maste <emaste> |
Status: | Closed FIXED | ||
Severity: | Affects Only Me | Flags: | emaste:
mfc-stable11?
emaste: mfc-stable10- emaste: mfc-stable9- |
Priority: | --- | ||
Version: | CURRENT | ||
Hardware: | Any | ||
OS: | Any | ||
See Also: |
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206039 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206381 |
Description
Ed Maste
2016-01-18 22:04:40 UTC
This is happening because libunwind steps on the thread stack guard page. libpolyml/sighandler.cpp for the signal handler thread calls pthread_attr_setstacksize(min(4096, PTHREAD_STACK_MIN)) - on FreeBSD/x86 PTHREAD_STACK_MIN is 2k so we end up with the 4k min, but it seems llvm-libunwind needs more stack space for the _Unwind_ForcedUnwind. The large stack usage comes from this function -- note sub $0x878,%rsp: template <typename A, typename R> void UnwindCursor<A, R>::setInfoBasedOnIPRegister(bool isReturnAddress) { 92d0: 55 push %rbp 92d1: 48 89 e5 mov %rsp,%rbp 92d4: 41 57 push %r15 92d6: 41 56 push %r14 92d8: 41 55 push %r13 92da: 41 54 push %r12 92dc: 53 push %rbx 92dd: 48 81 ec 78 08 00 00 sub $0x878,%rsp from the stack-allocated typename CFI_Parser<A>::PrologInfo prolog 1229 #if _LIBUNWIND_SUPPORT_DWARF_UNWIND 1230 // There is no static unwind info for this pc. Look to see if an FDE was 1231 // dynamically registered for it. 1232 pint_t cachedFDE = DwarfFDECache<A>::findFDE(0, pc); 1233 if (cachedFDE != 0) { 1234 CFI_Parser<LocalAddressSpace>::FDE_Info fdeInfo; 1235 CFI_Parser<LocalAddressSpace>::CIE_Info cieInfo; 1236 const char *msg = CFI_Parser<A>::decodeFDE(_addressSpace, 1237 cachedFDE, &fdeInfo, &cieInfo); 1238 if (msg == NULL) { 1239 typename CFI_Parser<A>::PrologInfo prolog; 1240 if (CFI_Parser<A>::parseFDEInstructions(_addressSpace, fdeInfo, cieInfo, 1241 pc, &prolog)) { (lldb) p sizeof(PrologInfo) (unsigned long) $10 = 1952 By comparison, the equivalent struct in the GCC unwinder: (lldb) p sizeof(_Unwind_FrameState) (unsigned long) $3 = 384 as it has storage for only 18 registers: (lldb) p sizeof(fs.regs.reg) / sizeof(fs.regs.reg[0]) (unsigned long) $9 = 18 while LLVM's libunwind has storage for: kMaxRegisterNumber = 120 Fixed by llvm-libunwind update in r302450 A commit references this bug: Author: emaste Date: Sat Jul 9 00:35:21 UTC 2016 New revision: 302475 URL: https://svnweb.freebsd.org/changeset/base/302475 Log: libunwind: limit stack usage in unwind cursor This may be reworked upstream but in the interim should address the stack usage issue reported in the PR. PR: 206384 MFC after: 1 week Sponsored by: The FreeBSD Foundation Changes: head/contrib/llvm/projects/libunwind/include/__libunwind_config.h head/contrib/llvm/projects/libunwind/src/DwarfParser.hpp A commit references this bug: Author: emaste Date: Fri Jul 22 17:34:29 UTC 2016 New revision: 303196 URL: https://svnweb.freebsd.org/changeset/base/303196 Log: MFC libunwind improvements r302450: libunwind: update to upstream snapshot r272680 The key improvement is that it may be built without cross-unwinding support, which significantly reduces the stack space requirement. r302456: libunwind: enable only the native unwinder by default This significantly reduces stack space requirements, and runtimes require only native unwinding. r302475: libunwind: limit stack usage in unwind cursor This may be reworked upstream but in the interim should address the stack usage issue reported in the PR. r303016: llvm-libunwind: use conventional (non-Darwin) X86 register numbers For historical reasons Darwin/i386 has ebp and esp swapped in the eh_frame register numbering. That is: Darwin Other Reg # eh_frame eh_frame DWARF ===== ======== ======== ===== 4 ebp esp esp 5 esp ebp ebp Although the UNW_X86_* constants are not supposed to be coupled to DWARF / eh_frame numbering they are currently conflated in LLVM libunwind, and thus we require the non-Darwin numbering. PR: 206384 Approved by: re (kib) Sponsored by: The FreeBSD Foundation Changes: _U stable/11/ stable/11/contrib/llvm/projects/libunwind/include/__libunwind_config.h stable/11/contrib/llvm/projects/libunwind/include/libunwind.h stable/11/contrib/llvm/projects/libunwind/src/AddressSpace.hpp stable/11/contrib/llvm/projects/libunwind/src/CompactUnwinder.hpp stable/11/contrib/llvm/projects/libunwind/src/Registers.hpp stable/11/contrib/llvm/projects/libunwind/src/Unwind-EHABI.cpp stable/11/contrib/llvm/projects/libunwind/src/UnwindCursor.hpp stable/11/contrib/llvm/projects/libunwind/src/UnwindLevel1.c stable/11/contrib/llvm/projects/libunwind/src/UnwindRegistersRestore.S stable/11/contrib/llvm/projects/libunwind/src/UnwindRegistersSave.S stable/11/contrib/llvm/projects/libunwind/src/config.h stable/11/contrib/llvm/projects/libunwind/src/libunwind.cpp stable/11/gnu/lib/libgcc/Makefile A commit references this bug: Author: emaste Date: Mon Jul 25 19:37:11 UTC 2016 New revision: 303318 URL: https://svnweb.freebsd.org/changeset/base/303318 Log: Merge LLVM libunwind fixes r302475: libunwind: limit stack usage in unwind cursor This may be reworked upstream but in the interim should address the stack usage issue reported in the PR. r303061: libunwind: Properly align _Unwind_Exception. _Unwind_Exception is required to be double word aligned. GCC has interpreted this to mean "use the maximum useful alignment for the target" so follow that lead. PR: 206384 (r302475) Obtained from: LLVM review D22543 (r303061) Approved by: re (gjb) Changes: _U stable/11/ stable/11/contrib/llvm/projects/libunwind/include/__libunwind_config.h stable/11/contrib/llvm/projects/libunwind/include/unwind.h stable/11/contrib/llvm/projects/libunwind/src/DwarfParser.hpp |