C implementations of the C++ ABI

[Mark Mitchell]

I don't know if we've fully considered the impact of the C++ ABI on
tools that generate C code to implement C++.  Examples of these
include the KAI C++-to-C optimizing compiler, various error-checking
tools, and compilers for languages other than C++.  (For example, a
Python compiler might well generate C code, but conforming to the ABI,
so that it could be linked with C++ programs.)  The GNU standard IO
library manually creates vtables, and C structures that mirror C++
object layouts.

There's a reason that these tools don't generate/use C++.  In KAI,
it's because they're trying to compile C++ to C -- they are performing
optimizations that many C++ compilers don't manage.  In general, the
reason is that C, despite the efforts of the C++ ABI committee, will
probably be a more portable language than C++ for years to come.
Besides the ABI issues, there are tons of issues regarding language
conformance, library conformance, template model, etc.  Most vendors
still have a ways to go to reach full conformance, and even that won't
ensure easy interoperability with respect to things like templates.
Whereas, most modern C compilers can be invoked with `<compiler> -c
foo.c' and generally produce the `foo.o' that you expected.

So, I'm concerned that our ABI has constructs that are not
representable in C.  The ones that jump out at me our:

  o Thunks

    These don't concern me too much.  Generating a little bit of
    assembly gets you past these, and the performance wins are
    significant.

  o Exceptions

    There have always been exception-handling issues in C++-to-C
    translation, and related tools.  Generally, the people who do
    that don't care about exceptions, so we're probably OK here.

  o GP/address pairs in vtables

    This one concerns me the most.  I don't even know if there's 
    any kind of standard assembly syntax for this.  Is there?
    (If not, there should be -- otherwise, you can't say -S to your
    compiler and get anything sensible out.)

    (BTW, if there's only one GP/address pair per function that
    matters (which there normally would be, so that pointers to the
    same function compare equal), then you can do things like overrite
    the GP/address pair to automatically switch all calls to that
    function to a different place.  (Yes, I've seen programs that do
    this -- and where it seemed justifiable.)

All in all, I'm not really suggesting we change anything.  I'm just
trying to make sure we're aware that there's an issue, in case we're
not already aware.

--
Mark Mitchell                   mark at codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com