<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 4, 2014 at 12:42 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 class="">On Jun 3, 2014, at 3:06 PM, Albert Wong (王重傑) <<a href="mailto:ajwong@google.com" target="_blank">ajwong@google.com</a>> wrote:<br>
</div><div><blockquote type="cite"><div dir="ltr"><div class=""><div>I'm slightly confused at the semantics of the defines. In my head, "zero cost" versus SJLJ are one dimension. Then within ZeroCost, there's the Itanium ABI (with DWARF encoding) and the Arm EABI (with EHABI encoding).</div>
<div><br></div><div>Thus, I would have expected __arm__ to be both "zero cost" as well as EHABI.</div><div><br></div></div><div>Is my understanding incorrect? (It very well may be…)</div></div></blockquote></div>
</div></blockquote><div>(crap...that was supposed to say "it very well may NOT be"....I meant to express lack of confidence...not sound like a jerk. :( Sorry about that. )</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>Ok. At an abstract level ARM EHABI is “zero cost”. But looking at how unwind.h has been conditionalized, the EHABI stuff is under LIBCXXABI_ARM_EHABI and is almost completely disjoint with the Itanium APIs. </div>
<div><br></div><div>You guys are the experts on ARM EHABI. If you model it is a variant on the Itanium zero-cost API, then we can go down the path where _LIBUNWIND_BUILD_ZERO_COST_<u></u>APIS is true. </div><div><br></div>
<div>It would be nice to unify the LIBCXXABI_ARM_EHABI in the header with this config.h settings. Perhaps get rid of </div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>_LIBUNWIND_SUPPORT_ARM_EHABI_<u></u>UNWIND and just use LIBCXXABI_ARM_EHABI?</div>
</div></div></div></div></div></blockquote><div><br></div><div>I agree with the observation that the Itanium APIs are nearly disjoint. Unifying on LIBCXXABI_ARM_EHABI sounds like a pretty good idea. I think Dana is running with it.<br>
</div><div><br></div><div>Thanks for the quick feedback.</div><div><br></div><div>-Albert</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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><font color="#888888"><div><br></div><div>-Nick</div></font></span></div></div></div><div><div class="h5">
<div><br></div><br><blockquote type="cite"><div dir="ltr"><div><div><div class="gmail_extra"><div class="gmail_quote">On Tue, Jun 3, 2014 at 11:50 PM, Jonathan Roelofs <span dir="ltr"><<a href="mailto:jonathan@codesourcery.com" target="_blank">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">Nick,<br>
<br>
This combines with Logan's work, and implements the libunwind bits that Logan's patch relied on libgcc_s for, in order to get rid of that dependency.<br>
<br>
Jon<div><div><br>
<br>
On 6/3/14, 3:47 PM, Nick Kledzik wrote:<br>
</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><div>
Dana,<br>
<br>
Is this a separate implementation of ARM EHABI than what Logan proposed<br>
4/13/2014? Or is this this same, but broken into steps?<br>
<br>
<br>
<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">
+ }<br>
+ #define _LIBUNWIND_BUILD_ZERO_COST_<u></u>APIS (__i386__ || __x86_64__ ||<br>
__arm64__ || __arm__)<br>
+ #define _LIBUNWIND_BUILD_SJLJ_APIS 0<br>
+ #define _LIBUNWIND_SUPPORT_FRAME_APIS (__i386__ || __x86_64__)<br>
+ #define _LIBUNWIND_EXPORT __attribute__((visibility("<u></u>default")))<br>
+ #define _LIBUNWIND_HIDDEN __attribute__((visibility("<u></u>hidden")))<br>
+ #define _LIBUNWIND_LOG(msg, ...) fprintf(stderr, "libuwind: " msg, __VA_ARGS__)<br>
+ #define _LIBUNWIND_ABORT(msg) assert_rtn(__func__, __FILE__, __LINE__, msg)<br>
+<br>
+ #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<br>
#endif<br>
</blockquote>
There will be three unwinding models: zero-cost, sj-lj, and EHABI. So there<br>
should be three mutually exclusive build settings:<br>
_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 intended as ways that<br>
zero-cost unwind information could be encoded.<br>
<br>
The patch above turns on both _LIBUNWIND_BUILD_ZERO_COST_<u></u>APIS for all<br>
architectures, which is wrong. It also leaves _LIBUNWIND_BUILD_ZERO_COST_<u></u>APIS<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">danakj@google.com</a><br></div></div><div>
<mailto:<a href="mailto:danakj@google.com" target="_blank">danakj@google.com</a>>> 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">
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 laid out here:<br>
<a href="http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140526/106670.html" target="_blank">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>
</blockquote>
<br>
</div></blockquote><span><font color="#888888">
<br>
-- <br>
Jon Roelofs<br>
<a href="mailto:jonathan@codesourcery.com" target="_blank">jonathan@codesourcery.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">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/<u></u>mailman/listinfo/cfe-commits</a><br>
</font></span></blockquote></div><br></div></div></div></div>
</blockquote></div></div></div><br></div></blockquote></div><br></div></div>