Page MenuHomePhabricator

[libcxxabi] Don't process exceptions in cxa_handlers when they're disabled
ClosedPublic

Authored by phosek on Jul 3 2019, 7:02 PM.

Details

Summary

When exceptions are disabled, avoid their processing altogether.
This avoids pulling in the depenency on demangler significantly
reducing binary size when statically linking against libc++abi
built without exception support.

Diff Detail

Repository
rCXXA libc++abi

Event Timeline

phosek created this revision.Jul 3 2019, 7:02 PM

The only thing iffy about this is that it's not 100% clear to me what _LIBCXXABI_NO_EXCEPTIONS mean. It could either mean (a) that libc++abi itself doesn't use exceptions in its implementation, or (b) that it doesn't provide support for exceptions in the runtime, or both (a) and (b).

It clearly means at least (a) from a quick grep, however it's not clear to me that it also means (b).

phosek added a comment.Jul 9 2019, 4:24 PM

The only thing iffy about this is that it's not 100% clear to me what _LIBCXXABI_NO_EXCEPTIONS mean. It could either mean (a) that libc++abi itself doesn't use exceptions in its implementation, or (b) that it doesn't provide support for exceptions in the runtime, or both (a) and (b).

It clearly means at least (a) from a quick grep, however it's not clear to me that it also means (b).

We assumed both (a) and (b). This is really valuable for us since we use libc++abi built with _LIBCXXABI_NO_EXCEPTIONS when -fno-exceptions is specified which can save a lot of space in embedded use cases because we can avoid pulling in all the demangling code.

If _LIBCXXABI_NO_EXCEPTIONS is meant to imply just (a), could we introduce a second definition/option for (b), e.g. _LIBCXXABI_NO_EXCEPTIONS and _LIBCXXABI_HAS_NO_EXCEPTIONS?

FYIe, you can also prevent this symbol to be linked in by putting a cxa_demangle function in an obj file that gets linked first, like so: https://cs.chromium.org/chromium/src/third_party/android_crazy_linker/src/src/crazy_linker_wrappers.cpp?type=cs&q=cxa_demangle+file:android&sq=package:chromium&g=0&l=54 – but I agree that since cxa_demangle is so large, it'd be nice if the upstream version was behind some kind of define. Then we could set that and remove that hack in chromium too. I don't have an opinion on if that should be a new define or if _LIBCXXABI_NO_EXCEPTIONS should be reused. Actually, I think we build libcxxabi with exceptions enabled because some of our test code can in theory throw exceptions, but we have an external dumper so we don't need the stack from terminate() – so it'd be somewhat more convenient for us if we could turn off the stack from terminate() (and the pulling in of __cxa_demangle) while still being able to build without setting _LIBCXXABI_NO_EXCEPTIONS.

FYIe, you can also prevent this symbol to be linked in by putting a cxa_demangle function in an obj file that gets linked first, like so: https://cs.chromium.org/chromium/src/third_party/android_crazy_linker/src/src/crazy_linker_wrappers.cpp?type=cs&q=cxa_demangle+file:android&sq=package:chromium&g=0&l=54 – but I agree that since cxa_demangle is so large, it'd be nice if the upstream version was behind some kind of define. Then we could set that and remove that hack in chromium too. I don't have an opinion on if that should be a new define or if _LIBCXXABI_NO_EXCEPTIONS should be reused. Actually, I think we build libcxxabi with exceptions enabled because some of our test code can in theory throw exceptions, but we have an external dumper so we don't need the stack from terminate() – so it'd be somewhat more convenient for us if we could turn off the stack from terminate() (and the pulling in of __cxa_demangle) while still being able to build without setting _LIBCXXABI_NO_EXCEPTIONS.

We have a local libc++abi patch to just disable the demangler altogether under certain configurations because of similar size concerns. I never got around to upstreaming that, but it seems like something that's wanted by multiple people, at least.

@ldionne and @EricWF do you have any preference?

Bigcheese accepted this revision.Jul 10 2019, 6:43 PM

_LIBCXXABI_NO_EXCEPTIONS removes the exceptions abi from libc++abi, so I think this change as fine as __cxa_throw isn't even defined if _LIBCXXABI_NO_EXCEPTIONS is defined.

This revision is now accepted and ready to land.Jul 10 2019, 6:43 PM

FYIe, you can also prevent this symbol to be linked in by putting a cxa_demangle function in an obj file that gets linked first, like so: https://cs.chromium.org/chromium/src/third_party/android_crazy_linker/src/src/crazy_linker_wrappers.cpp?type=cs&q=cxa_demangle+file:android&sq=package:chromium&g=0&l=54 – but I agree that since cxa_demangle is so large, it'd be nice if the upstream version was behind some kind of define. Then we could set that and remove that hack in chromium too. I don't have an opinion on if that should be a new define or if _LIBCXXABI_NO_EXCEPTIONS should be reused. Actually, I think we build libcxxabi with exceptions enabled because some of our test code can in theory throw exceptions, but we have an external dumper so we don't need the stack from terminate() – so it'd be somewhat more convenient for us if we could turn off the stack from terminate() (and the pulling in of __cxa_demangle) while still being able to build without setting _LIBCXXABI_NO_EXCEPTIONS.

I also think adding a way to just disable demangling is fine, but it should be a separate patch.

ldionne requested changes to this revision.Jul 11 2019, 8:29 AM

Fine with this if @Bigcheese is, however I'd like this patch to include a change to the LIBCXXABI_ENABLE_EXCEPTIONS CMake option, which controls whether _LIBCXXABI_NO_EXCEPTIONS is defined. The option currently says "Use exceptions.", however it should say something along the lines of: "Provide support for exceptions in the runtime. When this is disabled, libc++abi does not support stack unwinding and other exceptions-related features".

This revision now requires changes to proceed.Jul 11 2019, 8:29 AM
phosek updated this revision to Diff 209343.Jul 11 2019, 2:35 PM

Done, I've updated the comment for the CMake option.

Bigcheese accepted this revision.Jul 11 2019, 2:52 PM

looks good. @ldionne are you happy with the changes?

ldionne accepted this revision.Jul 12 2019, 10:57 AM
This revision is now accepted and ready to land.Jul 12 2019, 10:57 AM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptJul 12 2019, 12:11 PM