[PATCH] Start abstraction of C++ abi's

[Michael Elizabeth Chastain]

Hi Daniel,

> Why is it necessary to have a long discussion about creating a directory
> for a bunch of related files?

In the best case it's a very short discussion:

. contributor describes their new files and their provisional dir structure
. head maintainer chooses the actual dir structure

Andrew Cagney asks:
> Can you walk people through exactly how you're introducing the C++ abi.

My take on Daniel's patch is:

The current code is full of stuff like this:

  /* symtab.h */
  /* Macro that yields non-zero value iff NAME is the prefix for C++ destructor
     names.  Note that this macro is g++ specific (FIXME).  */

  #define DESTRUCTOR_PREFIX_P(NAME) \
    ((NAME)[0] == '_' && is_cplus_marker ((NAME)[1]) && (NAME)[2] == '_')

This stuff is not just wrapped up in macros; it is all over the source code.
Like this:

  /* c-typeprint.c */
  int is_full_physname_constructor =
   ((physname[0] == '_' && physname[1] == '_'
     && strchr ("0123456789Qt", physname[2]))
    || STREQN (physname, "__ct__", 6)
    || DESTRUCTOR_PREFIX_P (physname)
    || STREQN (physname, "__dt__", 6));

Daniel wants to change these to real functions like "constructor_prefix_p"
and "destructor_prefix_p" which would make a call through a function
pointer to the appropriate version for the abi (gcc v2, gcc v3, hp-acc,
arm, whatever).

The advantages are:

. code that knows things about names gets collected into one place for
  each abi style that we support.  Right now it's a wild goose chase
  to find all the places in the code that know about the innards of
  abi data structures.  This makes it easier to support that new ABI,
  "g++ v3 abi", which is coming at us.

. existing macros get replaced by functions.  These particular macros
  are full of hairy conditionals that will be a lot more readable as
  functions.

I am in favor of this approach -- I think it is necessary to collect
all the abi guts into files this way in order to have something that
other people can maintain.  That's why I'm sticking my nose in.

andrew> This, unfortunatly, makes it sound like more than a cosmetic
andrew> change :-(

daniel> How so?
daniel> It wasn't able to detect destructors before, because it was looking
daniel> for the v2 abi stuff.

I think that Andrew is saying: something that fixes bug is "*more*
than cosmetic", which means that it needs more review than a purely
cosmetic change would.

I would like to see before-and-after test suite runs on two different
platforms with both v2 and v3 g++, and maybe hpux aCC.  That's a lot of
testing but this kind of change is prone to regression errors.

Michael