[cfe-dev] A proposal for ABI migrations in libc++

Chandler Carruth chandlerc at google.com
Tue Oct 1 18:51:19 PDT 2013


Brief thoughts... I think it would be desirable to be able to have more
than one stable ABI along side the"next" ABI. For example, FreeBSD and Mac
might want to different stable ABIs.

Also, I'd like a more friendly interface for users of the unstable ABI than
an internal libc++ macro... Maybe a clang switch could house it?
On Oct 1, 2013 6:43 PM, "Peter Collingbourne" <peter at pcc.me.uk> wrote:

> Hi,
>
> These thoughts are motivated by my rejected std::deque patch.
>
> In general I don't think we have a good mechanism for making
> ABI-breaking changes in libc++.  The existing mechanism is to
> increment _LIBCPP_ABI_VERSION and make all ABI-breaking changes in
> the same commit along with the increment.  This makes it difficult for
> ABI-breaking changes to be developed incrementally, as there is no good
> place to keep the changes until the ABI-breaking megapatch; complicates
> debugging, as it would be difficult to bisect an ABI-breaking megapatch;
> and fails to accommodate implementors who are not constrained by ABI
> compatibility requirements.
>
> The proposal I have in mind is to introduce a macro, _LIBCPP_ABI_NEXT,
> which all ABI-breaking changes are made conditional on.  Defining this
> macro will cause _LIBCPP_ABI_VERSION to be defined to some arbitrary
> non-numeric value, such as "next" (without quotes).  The lib/buildit
> and test/testit scripts are modified so that the library can be built
> and tested with or without _LIBCPP_ABI_NEXT defined.  Any implementor
> who does not have ABI compatibility requirements for libc++ may compile
> the library with _LIBCPP_ABI_NEXT defined, but the implementor must
> ensure that the compiler defines this macro in every C++ translation
> unit.
>
> When we are ready to make an ABI transition, the value of
> _LIBCPP_ABI_VERSION is incremented and every place in the source code
> which is conditional on the definition of _LIBCPP_ABI_NEXT is updated
> as if the macro were defined.
>
> Thoughts?
>
> Thanks,
> --
> Peter
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131001/0e36a49e/attachment.html>


More information about the cfe-dev mailing list