<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 4, 2014 at 1:55 AM, Nick Kledzik <span dir="ltr"><<a href="mailto:kledzik@apple.com" target="_blank" class="cremed">kledzik@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div><div class="h5"><div>On Jun 3, 2014, at 4:45 PM, Dana Jansens <<a href="mailto:danakj@google.com" target="_blank" class="cremed">danakj@google.com</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 4, 2014 at 1:36 AM, Jonathan Roelofs <span dir="ltr"><<a href="mailto:jonathan@codesourcery.com" target="_blank" class="cremed">jonathan@codesourcery.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><br>
<br>
On 6/3/14, 5:26 PM, Albert Wong (王重傑) wrote:<br>
</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>
On Wed, Jun 4, 2014 at 12:42 AM, Nick Kledzik <<a href="mailto:kledzik@apple.com" target="_blank" class="cremed">kledzik@apple.com</a><br></div><div>
<mailto:<a href="mailto:kledzik@apple.com" target="_blank" class="cremed">kledzik@apple.com</a>>> wrote:<br>
<br>
On Jun 3, 2014, at 3:06 PM, Albert Wong (王重傑) <<a href="mailto:ajwong@google.com" target="_blank" class="cremed">ajwong@google.com</a><br></div><div>
<mailto:<a href="mailto:ajwong@google.com" target="_blank" class="cremed">ajwong@google.com</a>>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm slightly confused at the semantics of the defines. In my head, "zero<br>
cost" versus SJLJ are one dimension. Then within ZeroCost, there's the<br>
Itanium ABI (with DWARF encoding) and the Arm EABI (with EHABI encoding).<br>
<br>
Thus, I would have expected __arm__ to be both "zero cost" as well as EHABI.<br>
<br>
Is my understanding incorrect? (It very well may be…)<br>
</blockquote>
<br>
(crap...that was supposed to say "it very well may NOT be"....I meant to express<br>
lack of confidence...not sound like a jerk. :( Sorry about that. )<br>
<br>
Ok. At an abstract level ARM EHABI is “zero cost”. But looking at how<br>
unwind.h has been conditionalized, the EHABI stuff is under<br>
LIBCXXABI_ARM_EHABI and is almost completely disjoint with the Itanium APIs.<br>
<br>
You guys are the experts on ARM EHABI. If you model it is a variant on the<br>
Itanium zero-cost API, then we can go down the path where<br></div>
_LIBUNWIND_BUILD_ZERO_COST___<u></u>APIS is true.<div><br>
<br>
It would be nice to unify the LIBCXXABI_ARM_EHABI in the header with this<br>
config.h settings. Perhaps get rid of<br></div>
_LIBUNWIND_SUPPORT_ARM_EHABI__<u></u>_UNWIND and just use LIBCXXABI_ARM_EHABI?<div><br>
<br>
<br>
I agree with the observation that the Itanium APIs are nearly disjoint.<br>
Unifying on LIBCXXABI_ARM_EHABI sounds like a pretty good idea. I think Dana<br>
is running with it.<br>
</div></blockquote>
I would rather this didn't happen.<br>
<br>
I think it is important to maintain libunwind and libc++abi as two separate projects, and unifying this macro across the two of them is going to make that separation even harder to keep.<br></blockquote></div></div></div>
</blockquote></div></div><div>Yes, there has been talk of moving the unwinder to compiler-rt. </div><div class=""><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div>
<div>
In our repo we've been mostly using LIBCXX_ARM_EHABI, the _LIBUNWIND_SUPPORT macro was pretty redundant and rarely used by us, we just ended up with both somehow.</div><div><br></div><div>At this point we're pretty sure we are unable to nicely support the libunwind API nicely while sharing the exising UnwindLevel1 implementation with dwarf systems, since unw_step() is required to actually unwind the stack by the libunwind API but on ARM the unwind is done by the personality function which gets called from unwind_phase1, rather than by the unw_step().</div>
<div><br></div><div>This kind of mismatch makes it impossible to both share the unwind_level1 implementation with non-ARMEHABI, and also support libunwind. What we're planning to do for android is to not export any of the libunwind symbols and share code in UnwindLevel1 for now. What this means is that the libunwind API is somewhat just in the way for us if we're not implementing it (and it's not supposed to be exported by libc++abi anyhow).</div>
<div><br></div><div>A bit longer-term out we're considering splitting the ARM EHABI code off from the libunwind and friends code since it makes a number of things much more awkward for the EhABI spec (step for example, also floating point support. Antoine pointed out this in an email that has not gotten through moderation to the list yet.</div>
<div><br></div><div>All in all, we don't see the value in supporting the libunwind API, and would prefer to just support the ARM EHABI api (ie _Unwind_Foo), so just using the LIBCXX_ARM_EHABI makes sense to me. Please let me know what you think here.</div>
</div></div></div></blockquote><div><br></div></div><div>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>
</div></div></blockquote><div><br></div><div>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> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-Nick</div>
</font></span><div><div class="h5"><div><br></div><div><br></div><div><br></div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Jon<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<br>
Thanks for the quick feedback.<br>
<br>
-Albert<br>
<br>
<br>
-Nick<br>
<br>
<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
On Tue, Jun 3, 2014 at 11:50 PM, Jonathan Roelofs<br></div><div>
<<a href="mailto:jonathan@codesourcery.com" target="_blank" class="cremed">jonathan@codesourcery.com</a> <mailto:<a href="mailto:jonathan@codesourcery.com" target="_blank" class="cremed">jonathan@codesourcery.<u></u>com</a>>> wrote:<br>
<br>
Nick,<br>
<br>
This combines with Logan's work, and implements the libunwind bits<br>
that Logan's patch relied on libgcc_s for, in order to get rid of that<br>
dependency.<br>
<br>
Jon<br>
<br>
<br>
On 6/3/14, 3:47 PM, Nick Kledzik wrote:<br>
<br>
Dana,<br>
<br>
Is this a separate implementation of ARM EHABI than what Logan<br>
proposed<br>
4/13/2014? Or is this this same, but broken into steps?<br>
<br>
<br>
<br>
+ }<br></div>
+ #define _LIBUNWIND_BUILD_ZERO_COST___<u></u>APIS (__i386__ ||<div><br>
__x86_64__ ||<br>
__arm64__ || __arm__)<br>
+ #define _LIBUNWIND_BUILD_SJLJ_APIS 0<br>
+ #define _LIBUNWIND_SUPPORT_FRAME_APIS (__i386__ ||<br>
__x86_64__)<br>
+ #define _LIBUNWIND_EXPORT<br></div>
__attribute__((visibility("__<u></u>default")))<br>
+ #define _LIBUNWIND_HIDDEN<br>
__attribute__((visibility("__<u></u>hidden")))<div><br>
+ #define _LIBUNWIND_LOG(msg, ...) fprintf(stderr, "libuwind:<br>
" msg, __VA_ARGS__)<br>
+ #define _LIBUNWIND_ABORT(msg) assert_rtn(__func__,<br>
__FILE__, __LINE__, msg)<br>
+<br></div>
+ #define _LIBUNWIND_SUPPORT_COMPACT___<u></u>UNWIND 0<br>
+ #define _LIBUNWIND_SUPPORT_DWARF___<u></u>UNWIND 0<br>
+ #define _LIBUNWIND_SUPPORT_DWARF_INDEX 0<br>
+ #define _LIBUNWIND_SUPPORT_ARM_EHABI__<u></u>_UNWIND 1<div><br>
#endif<br>
<br>
There will be three unwinding models: zero-cost, sj-lj, and EHABI.<br>
So there<br>
should be three mutually exclusive build settings:<br></div>
_LIBUNWIND_BUILD_ZERO_COST___<u></u>APIS<br>
_LIBUNWIND_BUILD_SJLJ_APIS<br>
_LIBUNWIND_BUILD_ARM_EHABI___<u></u>APIS<br>
<br>
The SUPPORT_{COMPACT_UNWIND,DWARF_<u></u>__UNWIND,DWARF_INDEX} were<div><br>
intended as ways that<br>
zero-cost unwind information could be encoded.<br>
<br></div>
The patch above turns on both _LIBUNWIND_BUILD_ZERO_COST___<u></u>APIS<div><br>
for all<br>
architectures, which is wrong. It also leaves<br></div>
_LIBUNWIND_BUILD_ZERO_COST___<u></u>APIS<div><br>
true for __arm__ which is probably wrong too.<br>
<br>
-Nick<br>
<br>
<br>
On Jun 2, 2014, at 5:48 AM, Dana Jansens <<a href="mailto:danakj@google.com" target="_blank" class="cremed">danakj@google.com</a><br>
<mailto:<a href="mailto:danakj@google.com" target="_blank" class="cremed">danakj@google.com</a>><br></div><div>
<mailto:<a href="mailto:danakj@google.com" target="_blank" class="cremed">danakj@google.com</a> <mailto:<a href="mailto:danakj@google.com" target="_blank" class="cremed">danakj@google.com</a>>>> wrote:<br>
<br>
Hi Nick,<br>
<br>
Can you please take a look at this patch? With this, we define an<br>
UnwindInfoSections for ARM EHABI and are able to populate it.<br>
<br>
We'll start making use of this in future patches, as Albert<br>
laid out here:<br></div>
<a href="http://lists.cs.uiuc.edu/__pipermail/cfe-commits/Week-of-__Mon-20140526/106670.html" target="_blank" class="cremed">http://lists.cs.uiuc.edu/__<u></u>pipermail/cfe-commits/Week-of-<u></u>__Mon-20140526/106670.html</a><div>
<br>
<<a href="http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140526/106670.html" target="_blank" class="cremed">http://lists.cs.uiuc.edu/<u></u>pipermail/cfe-commits/Week-of-<u></u>Mon-20140526/106670.html</a>><br>
<br>
This patch builds and passes tests on Mac.<br>
<br>
Thanks,<br>
Dana<br>
<ehabi_address_space.diff><br>
<br>
<br>
<br>
--<br>
Jon Roelofs<br></div>
<a href="mailto:jonathan@codesourcery.com" target="_blank" class="cremed">jonathan@codesourcery.com</a> <mailto:<a href="mailto:jonathan@codesourcery.com" target="_blank" class="cremed">jonathan@codesourcery.<u></u>com</a>><br>
CodeSourcery / Mentor Embedded<br>
______________________________<u></u>___________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank" class="cremed">cfe-commits@cs.uiuc.edu</a> <mailto:<a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank" class="cremed">cfe-commits@cs.uiuc.<u></u>edu</a>><br>
<a href="http://lists.cs.uiuc.edu/__mailman/listinfo/cfe-commits" target="_blank" class="cremed">http://lists.cs.uiuc.edu/__<u></u>mailman/listinfo/cfe-commits</a><br>
<<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank" class="cremed">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/cfe-commits</a>><br>
<br>
<br>
</blockquote>
<br>
<br>
</blockquote><div><div>
<br>
-- <br>
Jon Roelofs<br>
<a href="mailto:jonathan@codesourcery.com" target="_blank" class="cremed">jonathan@codesourcery.com</a><br>
CodeSourcery / Mentor Embedded<br>
</div></div></blockquote></div><br></div></div>
</blockquote></div></div></div><br></div></blockquote></div><br></div></div>