<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jun 5, 2014 at 7:52 AM, Nick Kledzik <span dir="ltr"><<a href="mailto:kledzik@apple.com" target="_blank">kledzik@apple.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 style="word-wrap:break-word"><div>I’ve been at WWDC this week, so I’ll be slow on responding...</div>
<div><br></div><div>Do you have what the final code will look like after all the incremental patches you plan?</div></div></blockquote><div><br></div><div>Yes, see <a href="https://github.com/awong-dev/ndk/compare/upstream-llvm-ndkpatched...master#files_bucket">https://github.com/awong-dev/ndk/compare/upstream-llvm-ndkpatched...master#files_bucket</a> . To see the relevant diffs, click on "Files changed" tab and search for "libcxxabi/"</div>
<div><br></div><div>Also see <a href="http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140526/106670.html">http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140526/106670.html</a> which gave an outline of our upstreaming plan.</div>
<div> </div><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 style="word-wrap:break-word"><div> </div>
<div><br></div><div>I’d like to understand how much overlap there is between the Itanium unwinder and the EHABI unwinder. If there is not much, then trying to jam the two together with lots of conditionals will just make for hard to read code. And it is not like the algorithm can be improved in the future (so keeping them together would allow both unwinders to improve at once), because the algorithm just follows what the steps of the spec (Itanium and EHABI).</div>
<span class=""><font color="#888888"><div><br></div><div>-Nick</div></font></span><div><div class="h5"><br><div><div>On Jun 4, 2014, at 2:34 PM, Nico Weber <<a href="mailto:thakis@chromium.org" target="_blank">thakis@chromium.org</a>> wrote:</div>
<blockquote type="cite"><div dir="ltr">Is this new patch fine for now? (Everything else depends on it.)</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 4, 2014 at 3:27 AM, Dana Jansens <span dir="ltr"><<a href="mailto:danakj@google.com" target="_blank">danakj@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">Here's an updated patch that uses LIBCXX_API_EHABI. Since this is in AddressSpace.hpp which is part of the "libunwind" layer, I've duplicated the #define for this from the unwind.h which is part of the "_Unwind" layer to avoid including the unwind.h header which doesn't belong in AddressSpace.hpp.</div>
<div><div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 4, 2014 at 2:29 AM, Dana Jansens <span dir="ltr"><<a href="mailto:danakj@google.com" target="_blank">danakj@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"><div class="gmail_extra"><div class="gmail_quote"><div>On Wed, Jun 4, 2014 at 2:09 AM, Nick Kledzik <span dir="ltr"><<a href="mailto:kledzik@apple.com" target="_blank">kledzik@apple.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 style="word-wrap:break-word"><div><br><div><div>
On Jun 3, 2014, at 4:58 PM, Dana Jansens <<a href="mailto:danakj@google.com" target="_blank">danakj@google.com</a>> wrote:</div><br><blockquote type="cite"><blockquote class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;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 style="word-wrap:break-word"><br>The setjump-longjump is similar to this. It does not use the lower level libunwind APIs and it has its own phase1/phase2 unwinding code separate from the Itanium style. So, it makes sense to me for the ARM EHABI implementation to be in its own Unwind-ehabi.c file and do not use libunwind under it. This was part of why I thought of EHABI as being a different unwinder than the zero-cost unwinder in terms of _LIBUNWIND_BUILD_blah.</div>
</blockquote><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
We discussed making a change like that, but we're more concerned with upstreaming first right now, rather than keeping this all on a private repo. Since the way we developed this was sharing code with the itanium implementation as much as possible, are you okay with upstreaming it in this fashion and then looking at moving it away in the future?</div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
</div></blockquote></div></div>Can you be more specific about what you mean by “in this fashion” and “moving it away in the future”.</div></blockquote><div><br></div></div><div>Sure! What we have in our repo[1] is an implementation of ARM EHABI on top of the Itanium APIs. Initially we felt that made a lot of sense, though more recently we've started thinking about doing something different to fit the ARM EHABI requirements better. So, currently we are sharing code in unwind_level1, and AddressSpace and so on, as much as possible. This also helps keep our diffs smaller, I think.</div>
<div><br></div><div>In the future (maybe 6 months out) we could consider moving the implementation away from sharing code with itanium with #ifdefs, and moving to something more separate like SJLJ. But this isn't something we can realistically commit to doing right now, so it would make upstreaming a lot more difficult.</div>
<div><br></div><div>What we have is a functioning implementation that passes the tests, so I think it's not unreasonable. Concretely, this means using #if LIBCXX_ARM_EHABI throughout each of the three cxxabi, Unwind, and libunwind layers.</div>
<div><br></div><div>[1] <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> </div><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 style="word-wrap:break-word"><span><font color="#888888"><div>
<br></div><div>-Nick</div></font></span></div></blockquote></div><br></div></div>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div></div></div></blockquote></div><br></div></div>