Wrap sync_* builtins with libcpp_ functions to facility future customizations as atomic operations are unavailable on some targets.
Details
- Reviewers
danalbert EricWF jroelofs - Commits
- rGf7850fa8b64d: [libc++] Refactoring __sync_* builtins; NFC (Reland)
rG07f6efddc037: [libc++] Refactoring __sync_* builtins; NFC
rCXX307595: [libc++] Refactoring __sync_* builtins; NFC (Reland)
rCXX307591: [libc++] Refactoring __sync_* builtins; NFC
rL307595: [libc++] Refactoring __sync_* builtins; NFC (Reland)
rL307591: [libc++] Refactoring __sync_* builtins; NFC
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Lock-free atomic operations are also signal safe. Your code is not. While I don't know whether all this functions are not required to be signal safe, the general assertion is certainly questionable.
No, they are no signal safe. Per [1], "call to any library function, except the following signal-safe functions (note, in particular, dynamic allocation is not signal-safe):".
Locale.cpp should be fine with the change.
{set,get}_new_handler, {set,get}_unexpected_handler are not in the list.
I'm not very sure about "__libcpp_refstring". Seems it is only used by stdexcept. Although throw expression is explicitly stated as not signal safe, the ref counting of stdexcept might be. We can leave it unchanged.
On architectures without atomic instructions, the atomic built-ins cannot be lowered. If _LIBCPP_HAS_NO_THREADS is enabled, we should just use regular code.
Does "cannot be lowered" mean using them causes a compile error? If so I'm curious as to why you're the first one to run into this issue. If no compile error is caused then could you re-explain the rational for this change.
It would be really nice if we didn't cause the user unnecessary pain. Just because these functions aren't *required* to be signal safe doesn't necessarily mean they shouldn't be.
If this patch is indeed needed I would like to see it done similar to how [__libcpp_refcount_foo](https://github.com/llvm-mirror/libcxx/blob/master/include/memory#L3370) or the [src/include/atomic_support.h](https://github.com/llvm-mirror/libcxx/blob/master/src/include/atomic_support.h) logic is implemented, where instead of having #ifdef branches at each call site the logic has been abstracted away into a function.
That being said I would like to better understand the rational for this patch before proceeding.
When the builtin cannot be lowered, compiler just emits function call, which eventually becomes a linker error as no libs implement those functions (libgcc. libclang-rt, libc)
If the architecture doesn't support atomics (like cortex-m0), seems there is no software solution to make them signal-safe. Mutex/lock won't work.
How about we use "#ifdef GCC_ATOMIC_POINTER_LOCK_FREE < 2 && LIBCPP_HAS_NO_THREAD" ?
This can minimize the impact.
Why don't you start by adding __libcpp_sync_foo functions that we can use, then we can decide on what macros to use to guard their definition.
I'm not exactly sure where the __libcpp_sync_foo functions should live since they have to be used in __refstring, but I would just put wherever works at first.
@weimingz this refactoring LGTM. we can work out what the second set of definitions in __atomic_support looks like in another patch.
I'm not OK with adding a new header here. The problem is that __refstring requires using the new <__atomic_support> but <__refstring> shouldn't be a header anyway.
Could you please revert this till we figure out a better place for the builtins to live?
And they lack reserved names. Sorry for the repeated comment spam.
I'm going to go ahead and revert this myself. Please let me sign off next time.