[libcxx-dev] unstable ABI compiler assumptions

Thu Jun 27 11:26:48 PDT 2019

On Thu, Jun 27, 2019 at 1:32 PM Louis Dionne <ldionne at apple.com> wrote:

> My opinion:
>
> Unstable ABI means unstable, period. No guarantees whatsoever except if
> you compile the program with the same toolchain and same flags (within
> reason -- warnings shouldn't impact the ABI). Keeping the ABI stable is so
> difficult that claiming anything more complex than "full ABI compat" or "no
> ABI compat at all" is naive IMO. We'll end up breaking it in subtle ways
> anyway.
>

IMO, the unstable ABI ought to be managed in such a way as to make it
suitable to convert into an ABIv2 at some point in the future. So, it
should have "full ABI compatibility" just like the stable ABI -- but unlike
the stable ABI, only at a particular snapshot of the headers, not stable
across all versions.

(IOW, a person may change the unstable ABI at any time by editing the
header files, but with a particular snapshot of the headers, the
abi-stability properties ought to be equivalent)

> So I'm OK with the proposed change in principle (but not about the details
> of how it's implemented, see the review for details).
>
> On Jun 26, 2019, at 18:09, James Y Knight via libcxx-dev <
> libcxx-dev at lists.llvm.org> wrote:
>
> I think autodetection of ABI-changing features is a bad idea, no matter in
> the stable or unstable ABI.
>
> If libc++ wants to have an ABI which depends on certain new features from
> the compiler, that seems fine. But, when that ABI is enabled, trying to use
> the library with a compiler missing said feature should cause a compilation
> failure, not the silent use of an incompatible ABI.
>
>
> I agree, however with the tools we have today, I think that would mean
> encoding every single ABI-changing feature into an inline namespace. Then
> you'd get a link error instead of a runtime error.
>

That's not what I was going for at all. I think it's totally reasonable for
it to be up to users of the unstable ABI to not mix-and-match objects
compiled against different versions of the header files -- or else to
manage their own custom namespace to avoid such conflicts. All I'm saying
is that ABI-changing features ought to be enabled and disabled by editing
the __config header file, not by auto-detecting what compiler is used to
compile a particular source file.

That is, something like this:

#if defined(_LIBCPP_ABI_UNSTABLE)
#  if !defined(_LIBCPP_ABI_USE_NO_UNIQUE_ADDRESS)
#    define _LIBCPP_ABI_USE_NO_UNIQUE_ADDRESS  1
#  endif
#else
#  define _LIBCPP_ABI_USE_NO_UNIQUE_ADDRESS  0
#endif

#if defined(_LIBCPP_ABI_USE_NO_UNIQUE_ADDRESS)
#  if !__has_cpp_attribute(no_unique_address)
#    error "_LIBCPP_ABI_USE_NO_UNIQUE_ADDRESS requires the
no_unique_address attribute, which is not supported by your compiler."
#  endif
#endif

Louis
>

>
> That goes for both your cross-compiler and cross-language-version (and
> yes, we're getting the latter wrong already in the *stable* ABI now --
> and should fix that!)
>
> I also don't like the idea of the unstable ABI being incompatible with
> GCC. But, having the unstable ABI require a *new* version of GCC or Clang
> seems like a fine idea.
>
> So, concretely, I'd say that it should be fine to require support for
> no_unique_address in libc++'s unstable ABI (that's not clang-specific --
> and both GCC and Clang have implemented it).
>
>
> That said, I also wonder -- why must switching to no_unique_address change
> the ABI at all? Doesn't the way it was implemented mean that it's actually
> layout compatible to switch EBCO uses over to using no_unique_address? It'd
> sure be nice if no_unique_address could be used without ABI breakage when
> it's supported, even in the stable v1 ABI.
>
>
>
>
> On Mon, Jun 24, 2019, 7:28 PM Richard Smith via libcxx-dev <
> libcxx-dev at lists.llvm.org> wrote:
>
>> Hi,
>>
>> In https://reviews.llvm.org/D63744 I'm proposing a change to libc++ that
>> (unless we add an additional configuration flag) would mean that the
>> unstable ABI is not necessarily ABI-compatible with itself across different
>> compilers (in particular, one that supports a particular C++ attribute and
>> one that does not), nor between C++ language modes that support that
>> attribute and those that don't (which in both Clang and GCC is C++98/03
>> versus everything else).
>>
>> Do we think that's acceptable? Specifically:
>>
>>  * Do users of the unstable ABI need it to be ABI-compatible across
>> compiler versions and across compilers?
>>  * Do users of the unstable ABI need it to be ABI-compatible across C++
>> language modes (in particular, C++98 versus everything else)?
>>
>> And (deep breath) would version-locking the unstable ABI to the
>> corresponding version of Clang be acceptable?
>>
>> Thanks!
>> Richard
>> _______________________________________________
>> libcxx-dev mailing list
>> libcxx-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev
>>
> _______________________________________________
> libcxx-dev mailing list
> libcxx-dev at lists.llvm.org
> https://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/20190627/46d18dcf/attachment-0001.html>