Clarification around ABI version

Runtimes C++
1

From: Petr Hosek <phosek@chromium.org>
To: libcxx-dev@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++

  1. 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

2

Thanks Marshall and Eric, this clarifies the situation.

3

Thanks Marshall and Eric, this clarifies the situation.

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.

I’ve tried this and I think it’d work for us but there is one issue, with LIBCXX_ABI_UNSTABLE, libc++ build uses 1 as SOVERSION so we end up with libc++.so.1.0 as the filename which is technically incorrect. However, I don’t know what would be the best solution here.

We could use a string instead, e.g. ‘unstable’ but that might break clients who assume it’s a number (even though in ELF it’s an arbitrary string). We could also choose a meaningless number, e.g. 0, so the filename would be libc++.so.0.0.

Alternatively, we could disable the use of SOVERSION and VERSION for unstable ABI, SOVERSION is primarily needed using the library as part of the system installation, but for unstable ABI that’s unlikely to be the case. So the name of the library would be just libc++.so. However, that introduces another issue with the linkerscript which currently uses that name and uses the actual library as the input. We could rename the library to libc++_internal.so or we could make the Clang driver pass -lc++abi explicitly and avoid the need for the linkerscript. The latter is fine for Fuchsia since we don’t currently support other C++ ABI libraries, but may not work for other targets.

Do you have any opinions on this?

I would personally be more comfortable with explicitly encoding the fact that the library is unstable in its name. Exactly how we do that is not my primary concern, but just naming it libc++.so would not be great IMO.

Louis