ABI FAQ (was Re: g++ 2.95 and g++ 3.0)

[Nathan Myers <ncm at nospam dot cantrip dot org>]

On Mon, Nov 05, 2001 at 12:23:23PM +0200, Alexei Khlebnikov wrote:
> Oh, I have one more question. What does widely-mentioned "ABI" stand for?

This is an FAQ.  Let me essay an entry:
 
--------------------
"ABI" stands for "Application Binary Interface".  Conventionally, it 
refers to a great mass of details about how arguments are arranged on
the call stack and/or in registers, and how various types are arranged
and padded in structs.  A single CPU design may suffer multiple ABIs
designed by different development tool vendors who made different
choices, or even by the same vendor for different target applications
or compiler versions.  In ideal circumstances the CPU designer presents
one ABI and all the OSes and compilers use it.  In practice every ABI
omits details that compiler implementers (consciously or accidentally)
must choose for themselves.

That ABI definition suffices for compilers to generate code so a program
can interact safely with an OS and its lowest-level libraries.  Users 
usually want an ABI to encompass more detail, allowing libraries built 
with different compilers (or different releases of the same compiler!) 
to be linked together.  For C++, this includes many more details than 
for C, and CPU designers (for good reasons elaborated below) have not 
stepped up to publish C++ ABIs.  The details include virtual function 
implementation, struct inheritance layout, name mangling, and exception 
handling.  Such an ABI has been defined for GNU C++, and is immediately
useful for embedded work relying only on a "free-standing implementation"
that doesn't include (much of) the standard library.  It is a good basis
for the work to come.

A useful C++ ABI must also incorporate many details of the standard 
library implementation.  For a C ABI, the layouts of a few structs (such
as FILE, stat, jmpbuf, and the like) and a few macros suffice.  For C++, 
the details include the complete set of names of functions and types 
used, the offsets of class members and virtual functions, and the actual
definitions of all inlines.  C++ exposes many more library details to 
the caller than C does.  It makes defining a complete ABI a much bigger 
undertaking, and requires not just documenting library implementation 
details, but carefully designing those details so that future bug fixes
and optimizations don't force breaking the ABI.

There are ways to help isolate library implementation details from the 
ABI, but they trade off against speed.  Library details used in inner
loops (e.g. getchar) must be exposed and frozen for all time, but many 
others may reasonably be kept hidden from user code, so they may later
be changed.  Deciding which, and implementing the decisions, must happen
before you can reasonably document a candidate C++ ABI that encompasses
the standard library.
--------------------

Nathan Myers
ncm at cantrip dot org