N4028: Defining a Portable C++ ABI -- Herb Sutter

A new WG21 paper is available. A copy is linked below, and the paper will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4028

Date: 2014-05-23

Defining a Portable C++ ABI

by Herb Sutter


Goals, Non-Goals and Constraints

The primary goal is to:

  • Enable writing portable C++ code that will be compiled to an object file that can successfully:

    link with object files created by other conforming C++ compilers, or different versions of the same compiler, on the same platform; and 

    be called using FFIs from other language compilers/runtimes on the same platform, such as Java JNI and .NET PInvoke, if those FFI implementations support the (single) C++ ABI for that platform.

Here a target platform has the same meaning as de facto in C, namely the combination of:

  • Operating system: Such as Windows, OS X, Android, iOS, etc. The OS determines things like the binary format (such as PE, COFF, and ELF), the meaning of pointers (such as the legality of stealing low bits and the rules for high bits above bit 48), and more.
  • Processor family: Such as x86 or ARM. This affects the instruction set targeted by code generation, alignment, endian-ness, and more.
  • Bitness: Such as 32-bit or 64-bit. This affects the size and interpretation of pointers and references, size_t, and ptrdiff_t, and more.

This largely maps to “object files that could reasonably be expected to be part of a single executing program,” since a given single running program will be running on a given OS and processor at a time.

Examples and corollaries:

  • It should be possible to ship a single (not “fat”) compiled binary library for Windows x86 32-bit whose interface uses C++ features such as classes, virtual functions, and overloading, and have that be usable with code compiled by other compilers for Windows x86 32-bit.
  • It should be possible for an operating system API to expose a well abstracted modern C++ API that uses features like classes, virtual functions, and overloading, and also meets normal OS API requirements for ABI stability.

Notable non-goals and constraints:

  • We need not, and should not, try to guarantee some “universal C++ ABI” whereby a single ob-ject file could link with other object files on different platforms, such as 32-bit ARM Linux and 64-bit x86 Windows. That would defeat the original purpose of C and C++ to be a portable lan-guage that can generate executable code that is competitive with handcrafted platform-specific code on a given platform.
  • We must not change or restrict anything that is expressible today in platform-specific ways. Any new capabilities must be purely additive. All of the various incompatible compiler option flavors and standard library implementation flavors that are allowed today must still be preserved, both for compatibility and because most of them exist for good reasons (sometimes you do want packing, sometimes you do want a non-default calling convention, etc.).
  • We should accommodate that some vendors, such as Microsoft, feel they must be able to break the standard library ABI on every major release (see next section).
  • We should accommodate that some vendors, such as GCC, feel they must not break the standard library ABI (see next section).

Add a Comment

Comments are closed.

Comments (3)

0 0

Rick Wildes said on Jun 18, 2014 12:47 PM:

How will std::abi and extern "abi" work for debug builds? My thought would be they would always be comparable to release and when compiling debug many more types would be different from std and std::abi.
0 0

Rick Wildes said on Jun 20, 2014 06:25 AM:

On a related question (sorry for the multiple posts) will the things inside of std::abi have to be forced to bind to a run-time link-able version version of the platform run-time? Again this would mean if I was building a binary (DLL/SO/EXE) that statically linked in the C/C++ run-time so it was embedded privately into my binary most things in std::abi would likely have to be different types. In particular std::allocator<> would need to use the shared implementation and this would have a ripple effect making a lot of other types different.

I really like this proposal and I hope it gets into the standard (and implemented widely). Something like this is way overdue in C++ and the approach of this proposal seems to be a good way to address C++ ABI issues.
0 0

Cesar Mello said on Jul 30, 2014 10:17 AM:

Thank you so much for making the world a better place Herb!!! grin Best regards!