<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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
<br>
On 6/3/14, 5:26 PM, Albert Wong (王重傑) wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
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 class="">
<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 class="">
<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 class=""><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 class=""><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><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><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 class="">
<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 class="">
On Tue, Jun 3, 2014 at 11:50 PM, Jonathan Roelofs<br></div><div class="">
<<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 class=""><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 class=""><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 class=""><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 class=""><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 class=""><br>
for all<br>
architectures, which is wrong. It also leaves<br></div>
_LIBUNWIND_BUILD_ZERO_COST___<u></u>APIS<div class=""><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 class="">
<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 class="">
<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 class="HOEnZb"><div class="h5">
<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>