<div dir="ltr"><div>Hi all,<br><br></div><div>I have uploaded the patch to Phabricator for review.  Please have a look, and feel free to leave the comments.<br><br><a href="http://reviews.llvm.org/D3612">http://reviews.llvm.org/D3612</a> : Small change to unit test so that gcc can pass the unit test as well.<br>
<a href="http://reviews.llvm.org/D3613">http://reviews.llvm.org/D3613</a> : Implement the ARM EHABI exception handling.<br><br></div><div>Compared with the earlier patch sent to the mailing list, there are some differences:<br>

</div><div>(a) __cxa_begin_cleanup() and __cxa_end_cleanup() have been added so that the code compiled with arm-linux-gnueabi-g++ can link with libcxxabi.<br></div><div>(b) The barrier_cache data has been reordered so that it will be conform to ARM EHABI (except the __cxa_call_unexpected() which should be completely rewritten in the future.)<br>

</div><div>(c) Comments are cleaned up, and fixed various formatting issue.<br></div><div><br><br>On Mon, May 5, 2014 at 1:00 AM, Nico Weber wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">

I thought we were down to 4 or 6 test failures by now…<br></blockquote><br></div>I'm not sure if this is related to the environment or the compiler.  I am testing the code on Debian Wheezy armhf on QEMU, and compiling the code with clang.  Most of the failing test are SIGSEGV and SIGILL, although I haven't got time to figure out.<br>

<br><br><div class="gmail_extra"><div class="gmail_quote">On Mon, May 5, 2014 at 10:02 AM, Jonathan Roelofs<span dir="ltr"></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div><div></div></div>
This plan sounds OK to me, but I am a little hesitant. I want to be careful about how we use the reserved bits of the unwind caches, because some of it is implementation details of libgcc_s, and I'd rather not have a bunch of "this is unspecified in the spec, but we're doing it this way because libgcc's unwinder does it this way" in there permanently.  Can you add notes where such assumptions are made in the libc++abi part so that we can fix them later?<br>

</blockquote><div><br></div><div>AFAICT, I am using two undocumented APIs:<br><br></div><div>1. Using __gnu_unwind_frame() to unwind one frame.<br></div><div>2. In order to use _Unwind_GetLanguageSpecificData() and _Unwind_GetRegionStart() we have to copy the UCB to r12.<br>

<br></div><div>Both of them can be fixed if we have our own unwinding library, and I have written several comments to document these hacks.<br><br></div><div>Yet another missing part are __aeabi_unwind_cpp_pr0, __aeabi_unwind_cpp_pr1, and  __aeabi_unwind_cpp_pr2.  Currently, when the user program references these personality routines, the undefined symbol will be binded to the corresponding routine in libgcc.  This should be implemented in libcxxabi in the future; otherwise, link error will be raised when we replace libgcc with compiler-rt.<br>

<br></div><div>Sincerely,<br>Logan<br></div></div></div></div>