[libcxx-dev] Clarification around ABI version

[Marshall Clow]

On Mon, Oct 1, 2018 at 8:00 PM Petr Hosek via libcxx-dev <
libcxx-dev at lists.llvm.org> wrote:

>
>
>
> ---------- Forwarded message ----------
> From: Petr Hosek <phosek at chromium.org>
> To: libcxx-dev at lists.llvm.org
> Cc:
> Bcc:
> Date: Mon, 1 Oct 2018 20:00:09 -0700
> Subject: Clarification around ABI version
> This was raised in D52660. Today, libc++ recognizes at least 3 different
> ABI versions: v1, v2 (and above) and unstable, see
> https://github.com/llvm-mirror/libcxx/blob/master/include/__config#L66.
>

Not really.
There is V1.
There is V2 and unstable. Today, those are the same.


> There are several questions that were raised in that review that I'd like
> to get clarity on:
>
> 1. Is there a plan to eventually stabilize v2 and introduce v3 (and above)
> as the unstable version or is v2 going to be unstable forever?
>

We (the libc++ team) have no plans to do so - because we never ship a
libc++.
(We do have a mechanism to do so, but no plans)
The decision of what ABI to support is made by the people who ship libc++



> 2. What are the guarantees for v2? I understand that this ABI can still
> change, but I'm interested in testing and stability, shall we expect that
> v2 receives the same amount of coverage and that bugs specific to v2 will
> get resolved with the same priority as bugs specific to v1?
>
> Since the ABI version is part of the generated __config header, it's a
> vendor rather than per-target option which means it affects all targets
> that use libc++ headers from the toolchain.
>

Correct.


> This is fine for us since we always link libc++ statically on host and we
> don't have any plans to guarantee a stable C++ ABI on the target. The
> improvements seem to be worth using v2 over v1, but I'd like to better
> understand what the plans and guarantees are before committing to it.
>

This is not a choice that we (the libc++ maintainers) can make.
This is up to the people who build libc++.

Apple, for example, ships V1 on Mac OS X (i386 and x86_64), but offers a
different ABI on ARM64.
(at the very least, they define `_LIBCPP_ABI_ALTERNATE_STRING_LAYOUT`)

I have no idea what Android does.

Since you link libc++ statically, and have no abi concerns, I would use
`_LIBCPP_ABI_UNSTABLE`.
This contains changes/improvements/bug fixes that we were unable to ship
generally, because of ABI concerns.

Hope this helps.

-- Marshall
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20181001/31e5706d/attachment.html>