Created attachment 16902 [details] Example Source I've cross-compiled libc++, libc++abi and libunwind (All release versions of v3.8.1) with arm-linux-gnueabi-g++ v5.4.0 (as found on Ubuntu 16.04) to be linked statically. I then continue to use it to compile and link my application that throws and catches exceptions. Running this application fails with: Assertion failed: ttypeEncoding == DW_EH_PE_absptr && "Unexpected TTypeEncoding" (/path/to/libcxxabi/src/cxa_personality.cpp: get_shim_type_info: 350) I've attached an example application that should trigger this, as well as it's assembly.
Created attachment 16903 [details] Example Assembly
Sorry - I accidentally submitted the bug too soon. So I went through debugging the assertion failure, and it seems to be because GCC was generating a LSDA for main() (.LLSDA0) with TTypeEncoding = 0x90, while the existing code expects it to be 0x0. Copy+pasting the non-EHABI get_shim_type_info() (which *can* accept TTypeEncoding = 0x90) to replace the EHABI's seems to result in the exception being caught and handled properly.
So.. Does that mean there is no bug, and I should close the issue?
The bug is that the current implementation of get_shim_type_info() (for EHABI) can't handle TTypeEncoding != 0x0. While the non-EHABI seems to be able to handle it just fine, I don't know the DWARF specification well enough such that it won't break anything else. Otherwise I would have sent a patch, not a bug report :) https://github.com/llvm-mirror/libcxxabi/commit/05d51bcf was the commit that added it, so it might be worth CCing the author
Adding Logan, since it was his commit.
IMO, 0x90 (DW_EH_PE_pcrel|DW_EH_PE_indirect), which is emitted by GCC 4.9 (or newer), is the correct value. In addition, read_target2_value() in libcxxabi are performing pc-relative indirect load actually. However, due to a legacy reason, 0x00 (DW_EH_PE_absptr) should be supported as well. LLVM/Clang and GCC 4.6 (or earlier) are emitting 0x00. GCC changed its behavior around 2015 and that's the reason why I did not encounter this issue when I was writing those assertions. A quick workaround is to replace the assertions in question: > assert(ttypeEncoding == DW_EH_PE_absptr && "Unexpected TTypeEncoding"); with: > assert((ttypeEncoding & 0x0f) == DW_EH_PE_absptr && "Unexpected TTypeEncoding"); I wrote those assertions because I was assuming each entry took sizeof(uintptr_t) bytes. Thus, we can replace them with a weaker assertion. I will upload a patch for review ASAP.
Patch and test cases for this bug: https://reviews.llvm.org/D24085
Committed as https://reviews.llvm.org/rL286760 I am closing this bug. Please let me know if this change didn't fix your problem. Thanks.