This is an archive of the discontinued LLVM Phabricator instance.

[libcxxabi] Always use thread_local for cxa_exception_storage
ClosedPublic

Authored by smeenai on Nov 21 2022, 4:10 PM.

Details

Summary

This was previously guarded by HAS_THREAD_LOCAL, which was never set by
CMake and had to be specified manually. Android has been setting this to
solve https://github.com/android/ndk/issues/1200 [1], but every compiler
and platform libc++abi supports should have thread_local by now, so we
can just get rid of the fallback implementation and simplify things
significantly (including removing the now unused fallback calloc).

[1] https://android-review.googlesource.com/c/toolchain/llvm-project/+/1285596

Diff Detail

Event Timeline

smeenai created this revision.Nov 21 2022, 4:10 PM
Herald added a project: Restricted Project. · View Herald TranscriptNov 21 2022, 4:10 PM
smeenai requested review of this revision.Nov 21 2022, 4:10 PM
Herald added a project: Restricted Project. · View Herald TranscriptNov 21 2022, 4:10 PM
Herald added a reviewer: Restricted Project. · View Herald Transcript
MaskRay accepted this revision.Nov 21 2022, 6:37 PM

LGTM. Clang has some targets that do TLSSupported = false but they are not supported by libc++.

LGTM. Clang has some targets that do TLSSupported = false but they are not supported by libc++.

Do those targets support emulated TLS? Android didn't support ELF TLS until fairly recently, for example, so the thread_local path would end up using emulated TLS (which is using pthread under the hood), but this saves libc++abi from having to worry about those details or manually do the pthread equivalent.

ldionne accepted this revision.Nov 22 2022, 6:58 AM
This revision is now accepted and ready to land.Nov 22 2022, 6:58 AM
thakis added a subscriber: thakis.Nov 23 2022, 7:09 AM

This breaks tests for us on macOS/arm (https://luci-milo.appspot.com/ui/inv/build-8796707812197344321/test-results?q=StackSamplingProfilerTest.UnloadedLibrary) and android/x86 (https://logs.chromium.org/logs/chromium/buildbucket/cr-buildbucket/8796707998083656337/+/u/chrome_junit_tests__with_patch_/stdout?format=raw , look for [ FAILED ] org.chromium.chrome.features.start_surface.SecondaryTasksSurfaceViewBinderUnitTest.testSetTopMargin (603 ms)). Is that expected?

It's not. I'm out for a few days; could you revert this for me please?

It's not. I'm out for a few days; could you revert this for me please?

Will do, thanks.

Looks like the android/x86 failure also happens on other diffs, so that's very likely unrelated. The arm/mac thing looks like it might be real? Will confirm locally that it's indeed due to this patch and then revert if so.

I actually did come across breakage on several downstream platforms that apparently do not support thread_local. I'll have to investigate. I would support reverting this to give us time to investigate a bit.

It's not. I'm out for a few days; could you revert this for me please?

I'll do that now, but let's take the time to figure out what we can clean up here.

ldionne added inline comments.Nov 24 2022, 5:53 AM
libcxxabi/src/cxa_exception_storage.cpp
27

So IIUC, this was basically never defined previously, right?

Thanks for the revert.

We could take an intermediate approach where we detect thread_local support via CMake and turn on HAS_THREAD_LOCAL in that case, instead of removing the non-thread_local code path entirely. That'd let us shake out any issues with the thread_local path while also preserving support for other platforms (though I'm surprised we're still supporting platforms which have threads but not thread_local).

libcxxabi/src/cxa_exception_storage.cpp
27

Yup. This seems to go back to the original implementation of this code back in 2011, but it's hard to determine if this was intended to be automatically turned on e.g. via CMake if thread_local was detected.

Thanks for the revert.

We could take an intermediate approach where we detect thread_local support via CMake and turn on HAS_THREAD_LOCAL in that case, instead of removing the non-thread_local code path entirely. That'd let us shake out any issues with the thread_local path while also preserving support for other platforms (though I'm surprised we're still supporting platforms which have threads but not thread_local).

Yes, I'd support that approach. Let's call the macro _LIBCXXABI_HAS_THREAD_LOCAL, though. I'll commit to figuring out what's wrong on the platforms I saw that didn't support thread_local.

I'll be going on an extended vacation soon. If anyone needs this sooner, they should feel free to pick it up, otherwise I'll get to it when I'm back in February. (Similarly, there's no rush on our end for you to figure out the platform issues you observed.)