On 6/9/2014 2:31 PM, Botond Ballo wrote:
Portable C++ ABI:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4028.pdf
Perhaps a bit late to be saying this, but after reading this paper, I've
come to object to it.
A "portable" ABI can mean one of several things:
1. A well-defined, predictable interface that can be used for, e.g.,
FFI-type libraries.
2. An interface that allows different compilers to compile some of the
object files that make up a library and still have everything come out
the same (up to code generation/optimization differences).
3. Binary compatibility (to use the term in Java's spec) for class
implementations, which allows you can define what can and can't be
changed without breaking ABI compatibility.
The problem is that this paper achieves none of these. The main
proposals appear to boil down to the following:
1. Compilers must publish an official language ABI. Using this requires
extern "abi" linkage.
2. Declare a std::abi::* set of classes/functions/etc. This is
guaranteed ABI-compatible, and std::* is not guaranteed.
It explicitly mentions the issue that gcc can't make std::string
conforming to C++11 because doing so would require breaking ABI
compatibility, and it opines that making this move would allow gcc to
break the compatibility. This is a complete fallacy: breaking binary
compatibility is as much about the informal compatibility guarantees as
the formal ones. In Mozilla code, we explicitly stopped all binary
compatibility guarantees in Gecko 4 (early 2011). Even then, we decided
to make nsILocalFile an empty interface "for a little while" to avoid
breaking extensions... and 2 years, 2 months, 10 days later, we still
have 486 uses of this interface in mozilla-central alone. Our plans to
kill off XPIDL interfaces for the now-WebIDL-based DOM don't even extend
to nsIDOMElement and friends specifically for compatibility reasons.
Looking at the factors that block gcc's use of a conforming std::string,
this approach wouldn't expedite it at all.
Publishing official ABIs is rather meaningless: note that some details
of the Win64 C ABI are not officially published and had to be reverse
engineered (I think). It's also worth noting that MSVC's C++ ABI does
not appear to have a formal design or internal documentation, judging by
the presence of clear bugs in name mangling. It even may not be stable:
a few name manglings require computing hashCode(something). What blocks
interoperability with Win32's exception handling isn't the lack of a
specification but rather the existence of a patent [which I believe
expires this year].
The final--and biggest flaw--is that the envisioned mode of ABI
compatibility is to create a subset of the code that guarantees ABI
compatibility and make that subset grow steadily largely over time. I
don't think this works (witness the failure of the 8-bit MIME scheme in
this regard). extern "abi" can't be used by existing projects because it
doesn't exist yet; it can't be changed to in a future version if it
causes an ABI break because it breaks their compatibility. And if it
doesn't change ABI, then there's no point to it in the first place. New
projects can use it, but at moderate risk to compatibility with
pre-existing projects (depending on exact wording of specifications).
And so long as projects that don't use it exists, tools that want to do
FFI still need to worry about the "unstable" ABI. std::abi has the same
issues, with particularly stronger emphasis on the compatibility
mismatch between projects that use it and projects that don't.
So what we have, in short, is a paper that proposes an underdefined ABI
guarantee that, even were it fully defined, wouldn't be sufficient to be
usable by the people who most would want to use it.
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
