[libcxx-dev] Clarification around ABI version
Eric Fiselier
eric at efcs.ca
Tue Oct 2 12:09:46 PDT 2018
On Mon, Oct 1, 2018 at 11: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.
>
> 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?
>
Yes, the plan is to eventually stabilize v2 and introduce v3 (while
hopefully phasing out v1). The "unstable" configuration is really
just a way to say "give me the vX that is currently being staged).
> 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?
>
Once v2 is stable, it will have the same ABI guarentees as v1 (That is, it
won't change). When v2 is made stable, it will ideally become the default
and primary configuration for the library. At which point v1 will be
"deprecated-ish", but will continue to be maintained until all stakeholders
have migrated off it.
I imagine a timeline for migrating off v1 to take roughly 3-5 years.
My rough idea was to have at most three ABI versions in flight at any given
time. The default configuration (currently v1), the unstable configuration
where upcoming changes are staged, and a "deprecated" version that we're
working to remove (currently we don't have one).
>
> 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. 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.
>
>
>
> ---------- Forwarded message ----------
> From: Petr Hosek via libcxx-dev <libcxx-dev at lists.llvm.org>
> To: libcxx-dev at lists.llvm.org
> Cc:
> Bcc:
> Date: Mon, 1 Oct 2018 19:58:54 -0700 (PDT)
> Subject: [libcxx-dev] Clarification around ABI version
> _______________________________________________
> libcxx-dev mailing list
> libcxx-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20181002/41fdb2cf/attachment.html>
More information about the libcxx-dev
mailing list