C++ standard library ABI

[Jim Dehnert]

Jonathon and Christophe have made some thought-provoking comments about
the library implications of attempting to achieve ABI-conforming
portable code in some meaningful sense.  Since this discussion is no
doubt partially due to my minimal treatment in the Objectives section
of the summary page, let me try to clarify what my thinking has been on
the subject.  It is similar to that of Jonathon and Christophe.

To put it in context, the base ABI (nominally for C) contains several
parts which are all required for producing portable objects, but treat
distinct parts of the problem.  Chapter 3 deals with data layout,
procedure call interfaces, and other "Machine Interface" issues, i.e.
code sequences and data layouts that must match for objects to interact
successfully.  Most of the issues on our list so far fall in this
category, and very little is possible without agreement on them.

Chapters 4 and 5 deal with the representation of object files (ELF) and
the process of executing a program given that representation.  Some of
our issues touch on this category (.init/.fini issues, name mangling,
etc.).  It is usually straightforward to convert from one
representation to another, so not all such issues absolutely require
agreement.  But they're usually not hard to agree on -- easier than
writing conversion programs.

Chapter 6 defines a standard library API, in the sense of a set of
interfaces which may be found in the system libraries of any conforming
platform, typically including libc, libm, and similar basic facilities.
This is the area of concern when we start talking about the standard
library.  It is touched upon by the exception handling and
multithreading issues, but there's a great deal more that's not on the
issue list yet.

An ABI-conforming program, then, is one which uses the standard data
layouts and interface code, the standard object file formats, and
_only_ the Chapter 6 library interfaces.  If it uses additional external
calls, they must appear in DSOs supplied with the program.

What I believe to be a workable (and, I hope, achievable) approach is
to define as large a subset of the Standard Library as possible to be
in the platform libC.so (and possibly other DSOs), and then require that
the remaining parts be implemented by a compiler vendor in a "utility"
DSO that the user can deliver with his program, that doesn't use more
than the standard interface on a conforming platform, and that doesn't
clash with the standard interface or other vendors' utility DSOs.  Then,
if objects from multiple vendors' systems are combined, they may just
include all of the required utility DSOs with the host libC.so and
libc.so.

Now, it may seem that one could minimize the common interface in
libC.so, and push most of the functionality into the utility DSOs,
but that is not desirable, and probably not possible.  It is not
desirable because one of the benefits one obtains from
platform-specific system DSOs is platform-specific optimization.
It may not be possible because of things like iostreams -- mixing
different implementations in the same program is likely to be a
disaster.

So, here's what I suggest we do.  I would like someone to volunteer to
try to list the candidate common libC.so interfaces (presumably based
on a current implementation) sometime in the next month.  We can then
all take that as a basis for determining whether we need more material
or less in the base (likely both), and evaluating where the conformance
difficulties are going to be.  Does this sound reasonable?  Other
ideas?  A volunteer?

-	    Jim Dehnert		dehnert at sgi.com
				(650)933-4272