This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH] Start abstraction of C++ abi's
- To: ac131313 at cygnus dot com, dberlin at redhat dot com
- Subject: Re: [PATCH] Start abstraction of C++ abi's
- From: Michael Elizabeth Chastain <chastain at cygnus dot com>
- Date: Mon, 19 Feb 2001 14:11:05 -0800
- Cc: gdb-patches at sources dot redhat dot com
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