[libcxx-dev] unstable ABI compiler assumptions
James Y Knight via libcxx-dev
libcxx-dev at lists.llvm.org
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
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_USE_NO_UNIQUE_ADDRESS)
# define _LIBCPP_ABI_USE_NO_UNIQUE_ADDRESS 1
# define _LIBCPP_ABI_USE_NO_UNIQUE_ADDRESS 0
# 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."
> 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:
>> 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?
>> libcxx-dev mailing list
>> libcxx-dev at lists.llvm.org
> libcxx-dev mailing list
> libcxx-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the libcxx-dev