[PATCH] libcxxabi/unwind: Add support for ARM EHABI in AddressSpace.hpp
Dana Jansens
danakj at google.com
Tue Jun 3 16:45:03 PDT 2014
On Wed, Jun 4, 2014 at 1:36 AM, Jonathan Roelofs <jonathan at codesourcery.com>
wrote:
>
>
> On 6/3/14, 5:26 PM, Albert Wong (王重傑) wrote:
>
>> On Wed, Jun 4, 2014 at 12:42 AM, Nick Kledzik <kledzik at apple.com
>> <mailto:kledzik at apple.com>> wrote:
>>
>> On Jun 3, 2014, at 3:06 PM, Albert Wong (王重傑) <ajwong at google.com
>> <mailto:ajwong at google.com>> 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.
>
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.
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().
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).
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.
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.
>
> Jon
>
>>
>> Thanks for the quick feedback.
>>
>> -Albert
>>
>>
>> -Nick
>>
>>
>> On Tue, Jun 3, 2014 at 11:50 PM, Jonathan Roelofs
>>> <jonathan at codesourcery.com <mailto:jonathan at codesourcery.com>>
>>> 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 <danakj at google.com
>>> <mailto:danakj at google.com>
>>> <mailto:danakj at google.com <mailto:danakj at google.com>>>
>>> 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
>>> jonathan at codesourcery.com <mailto:jonathan at codesourcery.com>
>>> CodeSourcery / Mentor Embedded
>>> _________________________________________________
>>> cfe-commits mailing list
>>> cfe-commits at cs.uiuc.edu <mailto:cfe-commits at cs.uiuc.edu>
>>> http://lists.cs.uiuc.edu/__mailman/listinfo/cfe-commits
>>> <http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits>
>>>
>>>
>>>
>>
>>
> --
> Jon Roelofs
> jonathan at codesourcery.com
> CodeSourcery / Mentor Embedded
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140604/3530bdc1/attachment.html>
More information about the cfe-commits
mailing list