[cfe-dev] Proposal: Managing ABI changes in libc++

Marshall Clow mclow.lists at gmail.com
Fri Dec 19 18:19:21 PST 2014


> On Dec 19, 2014, at 2:24 PM, C Bergström <cbergstrom at pathscale.com> wrote:
> 
> 
> On Sat, Dec 20, 2014 at 4:14 AM, Eric Fiselier <eric at efcs.ca <mailto:eric at efcs.ca>> wrote:
> I don't really like allowing users to pick and choose which ABI
> changes to adopt. I personally don't see the use case for picking a
> subset of ABI changes to adopt. If you can adopt one ABI change,
> then why can't you adopt them all? Furthermore, as time goes on and
> more ABI changes are commited this could lead to quite a mess.

It’s not the users that will be picking and choosing.
I’m thinking of the people that ship libc++ as part of their systems.
[ Mac OS, FreeBSD, Android, iOS, etc ]

Each of them have different requirements for ABI stability.

Then there are the people/organizations who build and use their own libc++ libraries internally. They may or may not have any requirements for ABI stability, but they’re probably more flexible than the people who ship OS’es - whose change horizon is measured in years.

> 
> I also don't like having a stable version and an unstable version of
> the ABI. I'm afraid that by only introducing ABI changes into the
> "unstable ABI configuration" they will never be adopted.

Yes. There will be vendors who never adopt anything that is an ABI change, 
and I believe that supporting those people is important for libc++.

> 
> Instead I think we should version the ABI and introduce a series of
> stable ABI's under different versions. This allows us some sort of
> forward momentum and fewer configurations that need maintaining and
> testing.
> When a consumer can tolerate introducing an ABI break they can move to
> the most recent ABI version. After a given amount of time ABI versions
> would be deprecated.
> The only ABI versions that would be maintained indefinitely would be
> the current one.
> 
> This idea of ABI "version" paradigms well with real world packages. At some point we'll in theory have many libc++ packaged and released. If at the same time of the ABI breakage the libc++.so.${N} is incremented we have some tangible way to relay that information to potential end users.

I may be wrong, but I don’t see a use case (other than testing and/or libc++ development) for having multiple versions of libc++ on a system.
The goal is for it to be “the C++ standard library” - the one that you get from your system/distro vendor.

Changing the ABI of the libc++.dylib means that you have to rebuild *every piece of code* that links to that dylib. That’s a high bar.

What this proposal is about is providing those people (who distribute libc++) a method for managing the ABI that they ship.

> I'm personally against the #if hell which could result in multiple universes (I'd rather put a "stable" piece of code in a maintenance branch, but that's must my not-so-humble opinion.) It's like saying that the IR should be stable and never change... This is more user facing and gets more hand waiving, but at the end of the day it's the same sort of problem.
> 
> Every time a set of ABI breaking changes happen.. bump the lib version, cut a branch before the changes and move on with life... what's so wrong about this? Changes can be ported forward/backward to the branch as the owners want. Keep code complexity down..

At the cost of pushing the complexity onto the code owners, making sure that every non-ABI breaking change goes to all branches.

> Further - how do you QA libc++ when there's basically "2" correct ways to build it? Have the buildbots build it twice and report both results?

That’s what I would expect. Build once w/o any ABI breaks (because that’s the most common use case), and then once with them all.

If someone wants a library with a subset of the changes, they can build and test that.
For example, Apple would build with _LIBCPP_ABI_ALTERNATE_STRING_LAYOUT but no other changes for AArch64, because that’s what they ship today.


> For anyone who wants or demands stability.. I'd love to hear why a branch won't work..

It’s not “a branch”, it’s N branches (2^N if you consider combinations).

— Marshall


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141219/cc910c18/attachment.html>


More information about the cfe-dev mailing list