[PATCH] libcxxabi/unwind: Add support for ARM EHABI in AddressSpace.hpp

Nico Weber thakis at chromium.org
Sun Jun 22 14:02:35 PDT 2014


On Mon, Jun 16, 2014 at 1:15 PM, Nick Kledzik <kledzik at apple.com> wrote:

>
> On Jun 16, 2014, at 10:05 AM, Nico Weber <thakis at chromium.org> wrote:
>
> Nick, do you want us to put EHABI in a separate file before upstreaming,
>
> Yes.   It should be easy to de-conditionalize your current changes to
> UnwindLevel1.c and merge it with your Unwind-arm.c to make the new
> EHABI-only file.
>

Please take another look:
https://github.com/awong-dev/ndk/compare/upstream-llvm-ndkpatched...master#files_bucket

I renamed Unwind-arm.cpp to Unwind-EHABI.cpp, and moved all new code from
UnwindLevel1.c to there instead. I also reformatted the 80col lines. The
file still calls the unw_ functions, let me know if you want us to move off
those before upstreaming.

> * In general, the conditionals should consider the possibility of three
unwinders for arm: SJLJ, EHABI, and (someday maybe) Itanium.   For
instance, the new functions in UnwindRegisters{Save|Restore}.S should be
conditionalized with some EHABI conditional (not just __arm__ && !__APPLE),
and in Registers.hpp, all the new EHABI specific stuff in Registers_arm
should be conditionalized with ARM_EHABI.

Registers.hpp is currently free of preprocessor defines and relies on the
linker throwing out unused functions, so I didn't do this. Are you worried
about jumpTo() having different behavior? Right now, Registers_arm is only
used for EHABI unwinding, so it seems waiting with these ifdefs until
someone wants to add itanium unwinding for arm might be ok?

Thanks,
Nico

(ps: Please ignore the first change in UnwindRegistersSave.S, I think
that's some merge bug. https://github.com/awong-dev/ndk/pull/152 fixes it.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140622/13b80c11/attachment.html>


More information about the cfe-commits mailing list