[libcxxabi] Contributing ARM EHABI support for libcxxabi

Hi,

We’re evaluating using libc++ and libc++abi for Chromium/Android. While libc++abi has an unwind implementation since r192136, we noticed that there’s no support for unwinding using ARM EHABI-style unwind information, so in the last two weeks some of us (Albert Wong, Antoine Labour, Dana Jansens, and I) prototyped support for it, and we’re able to catch at least simple exceptions (you can look at our code here 1). We believe at least some of our code is ready for upstreaming.

A few questions:
1.) Is there interest for this upstream?
2.) Who should review this? Howard? Nick? Anton?
3.) r192136 didn’t add any test – how should testing of unwinding code work? Is running the exception tests in the libc++ suite enough?
4.) The unwind code doesn’t adhere to llvm style all that much – does it make sense to clang-format while it still has next to no svn history before landing other changes?

Thanks,
Nico

Hi,

We’re evaluating using libc++ and libc++abi for Chromium/Android. While libc++abi has an unwind implementation since r192136, we noticed that there’s no support for unwinding using ARM EHABI-style unwind information, so in the last two weeks some of us (Albert Wong, Antoine Labour, Dana Jansens, and I) prototyped support for it, and we’re able to catch at least simple exceptions (you can look at our code here [1]). We believe at least some of our code is ready for upstreaming.

A few questions:
1.) Is there interest for this upstream?
2.) Who should review this? Howard? Nick? Anton?
3.) r192136 didn’t add any test – how should testing of unwinding code work? Is running the exception tests in the libc++ suite enough?

I think at a minimum this should be done. I'm assuming you mean the libc++abi suite. No doubt the tests could be improved as well if you hit issues that are not currently tested.

Howard

Hi,

We’re evaluating using libc++ and libc++abi for Chromium/Android. While libc++abi has an unwind implementation since r192136, we noticed that there’s no support for unwinding using ARM EHABI-style unwind information, so in the last two weeks some of us (Albert Wong, Antoine Labour, Dana Jansens, and I) prototyped support for it, and we’re able to catch at least simple exceptions (you can look at our code here [1]). We believe at least some of our code is ready for upstreaming.

A few questions:
1.) Is there interest for this upstream?
2.) Who should review this? Howard? Nick? Anton?

I can.

3.) r192136 didn’t add any test – how should testing of unwinding code work? Is running the exception tests in the libc++ suite enough?

The Darwin libunwind project (http://opensource.apple.com/source/libunwind/libunwind-35.3/) on which this was based had some a small test suite, but it did not fit into the existing libcxxabi test suite which assumes target==host and every test is one .cpp file.

4.) The unwind code doesn’t adhere to llvm style all that much – does it make sense to clang-format while it still has next to no svn history before landing other changes?

The Unwind part conforms to llvm style much more than the rest of libcxxabi does :wink: I ran clang-format on the Unwind sources at one point during the port from darwin. Feel free to use clang-format on new code. My personal grip with clang-format is that it throws away all vertical alignment.

-Nick

1.) Is there interest for this upstream?

Yes!

2.) Who should review this? Howard? Nick? Anton?

Anton did a lot of work in it, would be good to get his reviews. I'd
also like to be copied.

3.) r192136 didn’t add any test – how should testing of unwinding code work?
Is running the exception tests in the libc++ suite enough?

Exception handling testing is not easy. The test-suite has some
regression testing on EH, which is currently disabled for ARM because
it didn't work at all, at a compiler level, not just libraries.

Adding minimal testing at a library level (kind of unit testing in
assembly) shouldn't be too hard. But to make sure it interoperates
well with LLVM, I'd run the EH part of the test-suite, it's quite
quick and reasonably comprehensive.

The rationale is that, if those regression tests pass, we're further
than we have even been. I'll be able to turn them on again on our
test-suite bot and we'll know we won't regress on them for the future.
Feel free to add new EH tests to the bundle, too, as you'll probably
find cases not predicted there.

cheers,
--renato

> Hi,
>
> We’re evaluating using libc++ and libc++abi for Chromium/Android. While
libc++abi has an unwind implementation since r192136, we noticed that
there’s no support for unwinding using ARM EHABI-style unwind information,
so in the last two weeks some of us (Albert Wong, Antoine Labour, Dana
Jansens, and I) prototyped support for it, and we’re able to catch at least
simple exceptions (you can look at our code here [1]). We believe at least
some of our code is ready for upstreaming.
>
> A few questions:
> 1.) Is there interest for this upstream?
> 2.) Who should review this? Howard? Nick? Anton?
I can.

> 3.) r192136 didn’t add any test – how should testing of unwinding code
work? Is running the exception tests in the libc++ suite enough?
The Darwin libunwind project (
Source Browser) on which
this was based had some a small test suite, but it did not fit into the
existing libcxxabi test suite which assumes target==host and every test is
one .cpp file.

Ok. I tried running at least the libc++abi test suite to make sure we don't
completely break exception handling on darwin, but it looks like the
buildit script doesn't build libunwind, and if I try to get it to compile
(attached), the compiler complains about mach-o/dyld_priv.h – is it
currently possible to run libc++abi tests for the Unwind bits of libc++abi
on darwin?

buildunwind.diff (822 Bytes)

> Hi,
>
> We’re evaluating using libc++ and libc++abi for Chromium/Android. While
libc++abi has an unwind implementation since r192136, we noticed that
there’s no support for unwinding using ARM EHABI-style unwind information,
so in the last two weeks some of us (Albert Wong, Antoine Labour, Dana
Jansens, and I) prototyped support for it, and we’re able to catch at least
simple exceptions (you can look at our code here [1]). We believe at least
some of our code is ready for upstreaming.
>
> A few questions:
> 1.) Is there interest for this upstream?
> 2.) Who should review this? Howard? Nick? Anton?
I can.

> 3.) r192136 didn’t add any test – how should testing of unwinding code
work? Is running the exception tests in the libc++ suite enough?
The Darwin libunwind project (
Source Browser) on which
this was based had some a small test suite, but it did not fit into the
existing libcxxabi test suite which assumes target==host and every test is
one .cpp file.

Ok. I tried running at least the libc++abi test suite to make sure we
don't completely break exception handling on darwin, but it looks like the
buildit script doesn't build libunwind, and if I try to get it to compile
(attached), the compiler complains about mach-o/dyld_priv.h – is it
currently possible to run libc++abi tests for the Unwind bits of libc++abi
on darwin?

If I copy
http://www.opensource.apple.com/source/dyld/dyld-132.13/include/mach-o/dyld_priv.h?txtto
include/mach-o/dyld_priv.h and build with the attached script, I'm
able
to build a libunwind.dylib that passes the tests and that fails them if I
add an early return to _Unwind_RaiseException. Would adding dyld_priv.h and
landing the attached patch be a good first step?

buildunwind.diff (2.13 KB)

Regarding dyld_priv.h, since it is always on my system in /usr/local/include, I had not realized the unwinder had that dependency. I posted a patch earlier to get the unwinder building on older darwins which did not have dyld support. I can update that patch so that the unwinder never need dyld_priv.h.

Regarding the build system, I think it brings up the bigger issue of what sort of build system we want for libcxxabi. The script is a quick way to get building. But, it is not how Apple actual builds the shipping libunwind (which is a local xcode project). What sort of build system would others like?

-Nick

Unless there is an overwhelming need to invest in something more custom, I
would vote for cmake. I'm still holding out hope for an end to build system
proliferation.

Regarding the build system, I think it brings up the bigger issue of what sort of build system we want for libcxxabi. The script is a quick way to get building. But, it is not how Apple actual builds the shipping libunwind (which is a local xcode project). What sort of build system would others like?

My $.02: Any build system will do, as long as there's are hooks to build the library using any compiler (e.g. pre-installed, clang++), install anywhere, and any link to any location of libc++, since the tests depend on a built libc++, not necesarily the system's. (libc++'s CMakefiles have a few hard-coded references to /usr/lib)

Here's my local Makefile I use to build libcxxabi:
https://github.com/fangism/libcxxabi/blob/powerpc-darwin8/lib/Makefile.darwin

and to test libcxxabi:
https://github.com/fangism/libcxxabi/blob/powerpc-darwin8/test/Makefile

I don't mind if libcxxabi has its own standalone build/Makefile, separate from LLVM's, since I plan to use it into a custom bootstrap flow.
</$.02>

David

Given that cmake is used widely in the rest of llvm, it makes sense to me to use it here too – but Howard has expressed resistance in the past, so I guess it’s up to him :slight_smile: Maybe that decision can be made independent of the rest and we can go with the tweak to what is there today?

> 3.) r192136 didn’t add any test – how should testing of unwinding code
work? Is running the exception tests in the libc++ suite enough?
The Darwin libunwind project (
http://opensource.apple.com/source/libunwind/libunwind-35.3/) on which
this was based had some a small test suite, but it did not fit into the
existing libcxxabi test suite which assumes target==host and every test is
one .cpp file.

Ok. I tried running at least the libc++abi test suite to make sure we
don't completely break exception handling on darwin, but it looks like the
buildit script doesn't build libunwind, and if I try to get it to compile
(attached), the compiler complains about mach-o/dyld_priv.h – is it
currently possible to run libc++abi tests for the Unwind bits of libc++abi
on darwin?

If I copy
http://www.opensource.apple.com/source/dyld/dyld-132.13/include/mach-o/dyld_priv.h?txt
to include/mach-o/dyld_priv.h and build with the attached script, I'm
able to build a libunwind.dylib that passes the tests and that fails them
if I add an early return to _Unwind_RaiseException. Would adding
dyld_priv.h and landing the attached patch be a good first step?

Regarding dyld_priv.h, since it is always on my system in
/usr/local/include, I had not realized the unwinder had that dependency. I
posted a patch earlier to get the unwinder building on older darwins which
did not have dyld support. I can update that patch so that the unwinder
never need dyld_priv.h.

Oh, and this would be appreciated :slight_smile:

I've no objection to a CMake system being put in. There's also one already in libcxx. Don't ask me to maintain it, I'm not qualified. And please don't delete the existing low-tech buildit script.

Howard

I just sent a proposed patch to the cfe-commits list. Let me know if that works for you.

-Nick

Nico,

Nico Weber wrote

1.) Is there interest for this upstream?
2.) Who should review this? Howard? Nick? Anton?

I'm interested in helping this make it's way upstream. I'll volunteer to
help Nick out with the review when the time comes. Are Github pull requests
to [1] your preferred method of collaboration to help polish this up for
mainline?

Nico Weber wrote

3.) r192136 didn’t add any test – how should testing of unwinding code
work? Is running the exception tests in the libc++ suite enough?

I'd like to see GTest style unit tests, especially for the personality
routines. I'm willing to help write some of them. Having a convenient way
to run them with target!=host is especially important to me (e.g. with qemu
or on real hardware).

Cheers,
Jon

[1]:

Nico,

Nico Weber wrote
> 1.) Is there interest for this upstream?
> 2.) Who should review this? Howard? Nick? Anton?

I'm interested in helping this make it's way upstream. I'll volunteer to
help Nick out with the review when the time comes. Are Github pull
requests
to [1] your preferred method of collaboration to help polish this up for
mainline?

Yes. Taking chunks of it and landing it upstream is useful too. (One simple
and useful thing to upstream would be a macro to differentiate between SJLJ
and dwarf-based exceptions (ours is currently called CXXABI_SJLJ, for
example).

Nico Weber wrote
> 3.) r192136 didn’t add any test – how should testing of unwinding code
> work? Is running the exception tests in the libc++ suite enough?

I'd like to see GTest style unit tests, especially for the personality
routines. I'm willing to help write some of them. Having a convenient way
to run them with target!=host is especially important to me (e.g. with qemu
or on real hardware).

Sounds good, but the libc++abi tests have worked fairly well for us so far,
and we're not passing all of them yet.

We're all somewhat busy with other things so upstreaming is moving way
slower than intended. (We did make some progress recently on passing tests
though.)

Looking forward to your help!

Nico

Hi Nico,

I'm going to try libunwind next, now that compiler-RT passes all tests
on the test-suite on ARM32, what's the status of the move from
libc++abi to compiler-rt and naming it libunwind? Is this going to
happen? Soon? Should I wait a bit before I start reporting bugs? Is
EHABI support in it, too? :smiley:

Sorry for so many questions, but I could give you a hand on testing
and moving things across to compiler-rt, if you need.

cheers,
--renato

> Yes. Taking chunks of it and landing it upstream is useful too. (One
simple
> and useful thing to upstream would be a macro to differentiate between
SJLJ
> and dwarf-based exceptions (ours is currently called CXXABI_SJLJ, for
> example).

Hi Nico,

I'm going to try libunwind next, now that compiler-RT passes all tests
on the test-suite on ARM32, what's the status of the move from
libc++abi to compiler-rt and naming it libunwind? Is this going to
happen?

I don't know. I heard that some people want to do this; I don't. (I'm not
against someone doing it, though.)

Soon? Should I wait a bit before I start reporting bugs? Is
EHABI support in it, too? :smiley:

There's EHABI support, but it's not fully complete. You can try running the
testit_android script for libc++abi from our repo to get an idea for how
much works.

I did some work on getting Apple’s unwind library in libc++ working on elf-ppc. Its unfinished. I did write an implementation of parsing the elf eh_frame but when I tested throwing an exception in client code, it couldn’t find the FDE entry there and it appears that you also have to parse debug_frame to get to the proper one. I was in the process of researching debug_frame when I stopped. If you want that work, I can give it to you.

Hi James,

Would be good to dump all that into a bug in bugzilla. Feel free to
assign it to me, I'll have a look when I finish with the EHABI support
in the back-end.

thanks!
--renato

I have 32bit PPC and VAX support working in NetBSD's fork of libunwind.
Beware that the amount of changes is extensive, but the extracting
.eh_frame_hdr support should be easy...

Joerg