libc++ ABI stability

Hello,

does the LLVM project make (or plan to make) any commitment with
regard to the ABI stability of libc++?

The plan is to keep the ABI semi-stable. The high level parts of the library are ABI-versioned using the C++11 feature inline namespaces. The current version is 1. This is considered an ABI version. And the ABI for any given version is meant to be fixed.

Every once in a great while (e.g. maybe for the next C++ standard), we could issue a new ABI, which would then live in a different inlined namespace (e.g. std::_2). There would be config macro to choose the ABI.

Some lower-level parts of the library are not ABI versioned. They live in namespace std only. These will remain stable until the sun swells up and swallows the earth (after that I can't vouch for it). These low level parts include:

* operator new/delete
* get/set new_handler
* typeinfo
* the exception classes

The exception classes not only have a stable ABI, their ABI is identical to that of gcc-4.2. This means you can throw exceptions across dyld boundaries and not worry which C++ std::lib the recipient of your exception is using (as long as that library is also ABI compatible with gcc-4.2).

Howard

... These will remain stable until the sun swells up and swallows
the earth (after that I can't vouch for it). These low level parts
include:

* operator new/delete
* get/set new_handler
* typeinfo
* the exception classes

The exception classes not only have a stable ABI, their ABI is
identical to that of gcc-4.2...

That's excellent news.

However, I take it new'ing an object in code that's using the GCC
libstdc++ and delete'ing in code using libc++, or vice-versa,
won't work?

thanks,

It depends on how libstdc++ and libc++ are built. If they both sit on top of the same libsupc++ or libc++abi, then memory ownership transfer is assured to be correct.

If they aren't built on the same foundation, then no, it is not assured. However from a practical point of view, it will *probably* still work because they both just drop through to malloc/free. But in that case, they will probably have different copies of the new handler. If either side of the shared lib boundary is counting on the behavior of a custom new handler, then having two copies of it would be problematic.

Howard

Every once in a great while (e.g. maybe for the next C++ standard), we could issue a new ABI, which would then live in a different inlined namespace (e.g. std::_2). There would be config macro to choose the ABI.

That seems fairly infrequent. I believe VS, for example, deliberately breaks ABI compatability across every crelease. Implementing things like SCARY iterators, otherwise cleaning up the footprint of collections, etc. Adding checked/debug iterators. All these would be ABI breaking, wouldn’t they? (well, the ABI of the code that uses libc++, that is - you couldn’t keep using a static/dynamic lib compiled with an old version of libc++ if you wanted to pick up the new version)

Or am I misunderstanding/missing something here?

  • David

I don't think you're misunderstanding.

And to be honest, my crystal ball works better on some days than others. Our intent is to try to hold the ABI steady for awhile, and when we do break it, version it. Inline namespaces have never been used for a large long-term project like this, so we'll see how it goes.

Howard

It depends on how libstdc++ and libc++ are built. If
they both sit on top of the same libsupc++ or libc++abi,
then memory ownership transfer is assured to be correct.

I'm expecting to be using Clang as provided with Apple Xcode,
on Mac OS X 10.7. I don't have this system set up yet. Should
I expect libstdc++ and libc++ to be configured this way on
that platform?

thanks,

I can not discuss future products (not even announced ones).

Howard

And to be honest, my crystal ball works better on some days than others. Our intent is to try to hold the ABI steady for awhile, and when we do break it, version it. Inline namespaces have never been used for a large long-term project like this, so we’ll see how it goes.

Fair enough - the plan holds regardless of whether you later discover you want to break it more frequently than you initially thought you’d need to, I was just curious about the idea that it would be as stable as all that. With any luck it’ll be easier to be stable from here than from back in the pre-standard or early standard days - at least in retail builds. Minimal footprints are provable, SCARY iterators are known (but who knows if other such optimizations would come up) - though I’m not sure about debug iterators, I imagine they could easily go through a few revisions (debug ABI compatibility might be a lower priority), and I can’t think of any other examples off-hand, but no doubt there are. Yep, really is a bit of rampant speculation though. Here’s hoping it comes out pretty close to right so it doesn’t have to change much.

Thanks,

  • David