[libcxx-dev] Is a compiler-rt shared spinlock implementation of any use to libcxx?

Mon May 20 13:55:41 PDT 2019

I'm a little confused about how said aformentioned freestanding
implementation would work. We (GWP-ASan + Scudo) can't depend on having
libcxx (we actually explicitly disable <https://reviews.llvm.org/D62048>
using of the c++ standard library for these libraries), and I don't know
where we could have a shared implementation live (that could be used by
both us and libcxx).

Would we have a spinlock implementation in libcxx and have that guarded by
a macro definition before the include of <mutex>, and then keep a
synchronised version in compiler-rt?

On Mon, May 20, 2019 at 10:10 AM Ben Craig <ben.craig at ni.com> wrote:

> Wouldn’t all the Scudo and sanitizer things count as part of the toolchain
> implementation though?  Having pieces of the toolchain use an alternative
> name seems pretty reasonable to me.
>
>
>
> If the goal is to have a freestanding std::mutex that is implemented as a
> spin lock, well, that’s different.  I could be convinced that’s a good
> thing to have, but I’m still a bit uneasy about it.
>
>
>
>
>
> *From:* jfbastien at apple.com <jfbastien at apple.com>
> *Sent:* Monday, May 20, 2019 11:27 AM
> *To:* Ben Craig <ben.craig at ni.com>
> *Cc:* Olivier Giroux <OGiroux at nvidia.com>; Mitch Phillips <
> mitchphillips at outlook.com>; libcxx-dev at lists.llvm.org; kostyak at google.com
> *Subject:* [EXTERNAL] Re: [libcxx-dev] Is a compiler-rt shared spinlock
> implementation of any use to libcxx?
>
>
>
> I think what developers *use* should definitely be named std::mutex. We
> indeed want to consider how the ABI is exposed, that’s a good question for
> libc++ maintainers.
>
>
>
>
>
> On May 20, 2019, at 6:23 AM, Ben Craig <ben.craig at ni.com> wrote:
>
>
>
> I think it’s fine to give such a class the same interface as std::mutex,
> just please don’t actually name it std::mutex.  I would be pretty concerned
> about ABI compatibility in that situation, as well as subtle interactions
> with things like condition_variable::wait.  cxxabi::__mutex, or almost any
> other identifier would be fine.
>
>
>
> *From:* libcxx-dev <libcxx-dev-bounces at lists.llvm.org> *On Behalf Of *Olivier
> Giroux via libcxx-dev
> *Sent:* Friday, May 17, 2019 7:55 PM
> *To:* JF Bastien <jfbastien at apple.com>; Mitch Phillips <
> mitchphillips at outlook.com>
> *Cc:* kostyak at google.com; libcxx-dev at lists.llvm.org
> *Subject:* [EXTERNAL] Re: [libcxx-dev] Is a compiler-rt shared spinlock
> implementation of any use to libcxx?
>
>
>
> That’s what makes the most sense to me, include <mutex> with a macro that
> freestanding would also use. Inside of that, I would have an implementation
> of standard mutex backed by atomics and the atomic_wait/atomic_notify_*
> functions, themselves configured with a macro to not rely on the OS in
> freestanding implementations.
>
>
>
> Olivier
>
>
>
> *From: *libcxx-dev <libcxx-dev-bounces at lists.llvm.org> on behalf of JF
> Bastien via libcxx-dev <libcxx-dev at lists.llvm.org>
> *Reply-To: *JF Bastien <jfbastien at apple.com>
> *Date: *Friday, May 17, 2019 at 4:40 PM
> *To: *Mitch Phillips <mitchphillips at outlook.com>
> *Cc: *"kostyak at google.com" <kostyak at google.com>, "
> libcxx-dev at lists.llvm.org" <libcxx-dev at lists.llvm.org>
> *Subject: *Re: [libcxx-dev] Is a compiler-rt shared spinlock
> implementation of any use to libcxx?
>
>
>
> I think it makes sense for libc++ to have a version of mutex which has the
> same API as the standard one, but for “freestanding” platforms such as
> yours. A flavor which mostly just spins and yields as in your review.
>
>
>
> I’m not sure how to best turn it on, though. Should it be controlled by a
> macro, and otherwise it just looks like you’re using <mutex>?
>
>
>
>
>
> On May 17, 2019, at 1:49 PM, Mitch Phillips via libcxx-dev <
> libcxx-dev at lists.llvm.org> wrote:
>
>
>
> Hi all,
>
>
>
> In a recent discussion
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D61923-231503272&d=DwMGaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=yw9dJtPZSvMNi00nrRSUlnN4NTQzKvXzHbd5w8ShH8A&s=uW10gtroz30NxGIUU3BvNH5efGnzv2tds3P49eY5ri4&e=>
>  from the reviews of GWP-ASan
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D60593&d=DwMGaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=yw9dJtPZSvMNi00nrRSUlnN4NTQzKvXzHbd5w8ShH8A&s=rKVj5vHVGEsEZRjMkiN2X6e0bAfdTY7iVW0laX2AO8o&e=>,
> it was mentioned that I should probably consult with cxx-dev to see whether
> they'd be interested in a common spinlock implementation.
>
>
>
> The problem is:
>
>  - Scudo hardened allocator (compiler-rt/lib/scudo) requires its own
> spinlock as it can't use the C++ standard library due to Fuchsia
> requirements.
>
>  - GWP-ASan (as it's packaged into Scudo) also requires a spinlock.
>
>  - Compiler-rt sanitizer_common also can't use c++ stdlib, and has its own
> spinlock. We can't reuse the sanitizer_common spinlock for Scudo/GWP-ASan
> as it's currently tightly coupled into sanitizer_common, and Scudo+Fuchsia
> can't afford the code size overhead of pulling the entire sanitizer_common
> library.
>
>
>
> The plan was to basically write a small standalone spinlock implementation
> that can be used by all three of these requirements. Would libcxx benefit
> by us making this an llvm-common spinlock rather than compiler-rt-common?
> If so, are there any requirements that we need to be aware of?
>
>
>
> Cheers,
>
> Mitch.
>
> _______________________________________________
> libcxx-dev mailing list
> libcxx-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_libcxx-2Ddev&d=DwQGaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=yw9dJtPZSvMNi00nrRSUlnN4NTQzKvXzHbd5w8ShH8A&s=SLhw06SYT_9fwfHOjm_nzQZ0LuPvmMe_b2gjd-VEFcc&e=>
>
>
> ------------------------------
>
> This email message is for the sole use of the intended recipient(s) and
> may contain confidential information.  Any unauthorized review, use,
> disclosure or distribution is prohibited.  If you are not the intended
> recipient, please contact the sender by reply email and destroy all copies
> of the original message.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20190520/cf11aeb7/attachment.html>