[cfe-dev] [libcxxabi] Contributing ARM EHABI support for libcxxabi

Nick Kledzik kledzik at apple.com
Tue Dec 3 15:45:54 PST 2013

On Dec 3, 2013, at 2:32 PM, Nico Weber <thakis at chromium.org> wrote:

> Hi,
> We’re evaluating using libc++ and libc++abi for Chromium/Android. While libc++abi has an unwind implementation since r192136, we noticed that there’s no support for unwinding using ARM EHABI-style unwind information, so in the last two weeks some of us (Albert Wong, Antoine Labour, Dana Jansens, and I) prototyped support for it, and we’re able to catch at least simple exceptions (you can look at our code here [1]). We believe at least some of our code is ready for upstreaming.
> A few questions:
> 1.) Is there interest for this upstream?
> 2.) Who should review this? Howard? Nick? Anton?
I can.

> 3.) r192136 didn’t add any test – how should testing of unwinding code work? Is running the exception tests in the libc++ suite enough?
The Darwin libunwind project (http://opensource.apple.com/source/libunwind/libunwind-35.3/) on which this was based had some a small test suite, but it did not fit into the existing libcxxabi test suite which assumes target==host and every test is one .cpp file. 

> 4.) The unwind code doesn’t adhere to llvm style all that much – does it make sense to clang-format while it still has next to no svn history before landing other changes?
The Unwind part conforms to llvm style much more than the rest of libcxxabi does ;-)  I ran clang-format on the Unwind sources at one point during the port from darwin.   Feel free to use clang-format on new code.  My personal grip with clang-format is that it throws away all vertical alignment. 


More information about the cfe-dev mailing list