On 6/3/14, 5:26 PM, Albert Wong (王重傑) wrote:
On Wed, Jun 4, 2014 at 12:42 AM, Nick Kledzik <[email protected]
<mailto:[email protected]>> wrote:
On Jun 3, 2014, at 3:06 PM, Albert Wong (王重傑) <[email protected]
<mailto:[email protected]>> wrote:
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).
Thus, I would have expected __arm__ to be both "zero cost" as well as EHABI.
Is my understanding incorrect? (It very well may be…)
(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. )
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.
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___APIS is true.
It would be nice to unify the LIBCXXABI_ARM_EHABI in the header with this
config.h settings. Perhaps get rid of
_LIBUNWIND_SUPPORT_ARM_EHABI___UNWIND and just use LIBCXXABI_ARM_EHABI?
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.
I would rather this didn't happen.
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.
Jon
Thanks for the quick feedback.
-Albert
-Nick
On Tue, Jun 3, 2014 at 11:50 PM, Jonathan Roelofs
<[email protected] <mailto:[email protected]>> wrote:
Nick,
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.
Jon
On 6/3/14, 3:47 PM, Nick Kledzik wrote:
Dana,
Is this a separate implementation of ARM EHABI than what Logan
proposed
4/13/2014? Or is this this same, but broken into steps?
+ }
+ #define _LIBUNWIND_BUILD_ZERO_COST___APIS (__i386__ ||
__x86_64__ ||
__arm64__ || __arm__)
+ #define _LIBUNWIND_BUILD_SJLJ_APIS 0
+ #define _LIBUNWIND_SUPPORT_FRAME_APIS (__i386__ ||
__x86_64__)
+ #define _LIBUNWIND_EXPORT
__attribute__((visibility("__default")))
+ #define _LIBUNWIND_HIDDEN
__attribute__((visibility("__hidden")))
+ #define _LIBUNWIND_LOG(msg, ...) fprintf(stderr, "libuwind:
" msg, __VA_ARGS__)
+ #define _LIBUNWIND_ABORT(msg) assert_rtn(__func__,
__FILE__, __LINE__, msg)
+
+ #define _LIBUNWIND_SUPPORT_COMPACT___UNWIND 0
+ #define _LIBUNWIND_SUPPORT_DWARF___UNWIND 0
+ #define _LIBUNWIND_SUPPORT_DWARF_INDEX 0
+ #define _LIBUNWIND_SUPPORT_ARM_EHABI___UNWIND 1
#endif
There will be three unwinding models: zero-cost, sj-lj, and EHABI.
So there
should be three mutually exclusive build settings:
_LIBUNWIND_BUILD_ZERO_COST___APIS
_LIBUNWIND_BUILD_SJLJ_APIS
_LIBUNWIND_BUILD_ARM_EHABI___APIS
The SUPPORT_{COMPACT_UNWIND,DWARF___UNWIND,DWARF_INDEX} were
intended as ways that
zero-cost unwind information could be encoded.
The patch above turns on both _LIBUNWIND_BUILD_ZERO_COST___APIS
for all
architectures, which is wrong. It also leaves
_LIBUNWIND_BUILD_ZERO_COST___APIS
true for __arm__ which is probably wrong too.
-Nick
On Jun 2, 2014, at 5:48 AM, Dana Jansens <[email protected]
<mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> wrote:
Hi Nick,
Can you please take a look at this patch? With this, we define
an
UnwindInfoSections for ARM EHABI and are able to populate it.
We'll start making use of this in future patches, as Albert
laid out here:
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>
This patch builds and passes tests on Mac.
Thanks,
Dana
<ehabi_address_space.diff>
--
Jon Roelofs
[email protected] <mailto:[email protected]>
CodeSourcery / Mentor Embedded
_________________________________________________
cfe-commits mailing list
[email protected] <mailto:[email protected]>
http://lists.cs.uiuc.edu/__mailman/listinfo/cfe-commits
<http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits>
--
Jon Roelofs
[email protected]
CodeSourcery / Mentor Embedded
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
