Is this new patch fine for now? (Everything else depends on it.)
On Wed, Jun 4, 2014 at 3:27 AM, Dana Jansens <[email protected]> wrote: > Here's an updated patch that uses LIBCXX_API_EHABI. Since this is in > AddressSpace.hpp which is part of the "libunwind" layer, I've duplicated > the #define for this from the unwind.h which is part of the "_Unwind" layer > to avoid including the unwind.h header which doesn't belong in > AddressSpace.hpp. > > > On Wed, Jun 4, 2014 at 2:29 AM, Dana Jansens <[email protected]> wrote: > >> On Wed, Jun 4, 2014 at 2:09 AM, Nick Kledzik <[email protected]> wrote: >> >>> >>> On Jun 3, 2014, at 4:58 PM, Dana Jansens <[email protected]> wrote: >>> >>> >>>> 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. >>>> >>> >>> 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? >>> >>> >>> Can you be more specific about what you mean by “in this fashion” and >>> “moving it away in the future”. >>> >> >> Sure! What we have in our repo[1] is an implementation of ARM EHABI on >> top of the Itanium APIs. Initially we felt that made a lot of sense, though >> more recently we've started thinking about doing something different to fit >> the ARM EHABI requirements better. So, currently we are sharing code in >> unwind_level1, and AddressSpace and so on, as much as possible. This also >> helps keep our diffs smaller, I think. >> >> In the future (maybe 6 months out) we could consider moving the >> implementation away from sharing code with itanium with #ifdefs, and moving >> to something more separate like SJLJ. But this isn't something we can >> realistically commit to doing right now, so it would make upstreaming a lot >> more difficult. >> >> What we have is a functioning implementation that passes the tests, so I >> think it's not unreasonable. Concretely, this means using #if >> LIBCXX_ARM_EHABI throughout each of the three cxxabi, Unwind, and libunwind >> layers. >> >> [1] >> https://github.com/awong-dev/ndk/compare/upstream-llvm-ndkpatched...master#commit_comments_bucket >> >> >>> >>> -Nick >>> >> >> > > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
