<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, May 30, 2014 at 9:11 PM, Albert Wong (王重傑) <span dir="ltr"><<a href="mailto:ajwong@google.com" target="_blank">ajwong@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hello cfe-commits (and Nick),<div><br></div>
<div>Last year, there were some small attempts to upstream our EHABI exception handling implementation but they fizzled out. We've picked up work again and would like to resume upstreaming. Here is a link to the diff (newly rebased on top of Tip-of-tree Libc++abi and libc++):</div>
<div><br></div><div> <a href="https://github.com/awong-dev/ndk/compare/upstream-llvm-ndkpatched...master#commit_comments_bucket" target="_blank">https://github.com/awong-dev/ndk/compare/upstream-llvm-ndkpatched...master#commit_comments_bucket</a></div>
<div><br></div><div>To see the relevant diffs, click on "Files changed" and search for "libc++abi."</div><div><br></div><div>Unlike last time, this implementation now passes all the libc++abi and almost all libc++ tests in debug mode for Android. There are still a few pieces missing (Floating point register support should be complete next week and force unwind is not implemented) however what's there should be enough to provide exception handling support without libgcc.</div>
<div><br></div><div>Our current plan is to try and upstream in the following chunks:</div><div> (1) Changes to AddressSpace.hpp needed to find the exidx section.</div><div> (2) Implementations for _Unwind_VRS_Get/Set, unw_getcontext, and then</div>
<div> stubs for the other _Unwind_VRS_* functions (basically get the non-floating-point</div><div> virtual register set working).</div><div> (3) Implementations of __aeabi_unwind_cpp_<span>pr{0,1,2} including the ARM unwinder</span></div>
<div><span> bytecode interpreter. (most EHABI exception support done here)</span></div><div><span> (4) Changes to the DWARF personality routine needed to support ARM.</span></div><div><span><br>
</span></div><div>Does that sound like a good plan? Would it be easier if we merged some of these chunks?</div>
<div><div><br></div><div>Thanks,</div><div>Albert</div></div></div>
</blockquote></div><br></div><div class="gmail_extra">Hi all,</div><div class="gmail_extra"><br></div><div class="gmail_extra">Regarding this topic, we had a question regarding the use of the libunwind integrated inside libcxxabi/src/Unwind/</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">While this is a good match for x86, it is a pretty poor match for ARM because of the way the ARM EHABI is specified. There are 3 main problems:</div><div class="gmail_extra">
<br></div><div class="gmail_extra">A- The loop in unwind_phase1/2 is based around unw_step, which is responsible for unwinding the stack frame, then extracting the personality routine to call it to figure out catch/cleanup/specification handlers. On ARM, the personality routine is not only responsible for the handlers, but also for the stack unwinding itself. What it means is that we either:</div>
<div class="gmail_extra"> - make unw_step do less on ARM (not the actual stack unwinding, just update internal data structures), which means it drifts away from what it's meant to be (and, among others, it can't be directly used to implement backtrace, etc.). This is what we have done in our current patchset.</div>
<div class="gmail_extra"> - skip unw_step in the ARM implementation of unwind_phase1/2 and instead use directly the underlying structures, maybe through a new API that would only update the internal structures.</div><div class="gmail_extra">
<br></div><div class="gmail_extra">B- The libunwind API is not expressive enough to implement certain aspects of the ARM spec. Among others #7.5 mentions the multiple floating point representations that don't fit into a singe unw_set_fpreg/unw_get_fpreg. Even with adding an extra API to specify that (what we've done), the API & implementation are still fairly inefficient to update several registers at a time, unless we add more ARM-specific extensions.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">C- Because of how the the PR is responsible for stack unwinding, it will never be possible to fully implement unwinding in a remote address space.</div><div class="gmail_extra">
<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">The question becomes, really, should we still use libunwind in the longer term on ARM. It feels like the value it provides is limited (since it can't do the actual unwinding for exception handling) and adds significant constraints. On the other hand, using it makes the ARM unwind_phase1/2 code much closer to x86.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">We would like to upstream what we have, but we are wondering what to do in the long term.</div><div class="gmail_extra">Would you have any guidance to provide?</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Thanks,</div><div class="gmail_extra">Antoine</div><div class="gmail_extra"><br></div></div>