Re: [RFA] Revised C++ ABI abstraction patches

[Jim Blandy <jimb at zwingli dot cygnus dot com>]

Eli Zaretskii <eliz@is.elta.co.il> writes:
> > 	* cp-abi-gnu-v2.c (gnu_v2_destructor_prefix_p,
> [...]
> > 	(gnu-v3-abi.o): Add.
> > 	(gnu-v2-abi.o): Add.
> 
> So what is it: cp-abi-gnu-v2 or gnu-v2-abi?  I prefer the latter, and I 
> thought that was the conclusion of the earlier discussions about that.

gnu-v[23]-abi were the names originally used in Daniel's patch.  I
changed them to cp-abi-gnu-v[23], for the reasons explained in the
ChangeLog entry provided with the patch:

	* cp-abi-gnu-v2.c, cp-abi-gnu-v3.c: Renamed from gnu-v2-abi.c
	and gnu-v3-abi.c, to show more clearly that they are
	implementations of cp-abi.h.
	* Makefile.in: Adjusted accordingly.

The names `gnu-v[23]-abi' just indicate that they're implementations
of some ABI, but the files are actually specifically dealing with C++
ABI's.  It's not meaningful to talk about an ABI without knowing the
source language, since an ABI is a binding between a particular source
language and a particular machine language.

For example, if we were to add Fortran support to GDB, each Fortran
compiler seems to have its own conventions for laying out dope
vectors, CHARACTER types, etc.  So in that case, too, we'd need to
have a generic interface that Fortran language support could use to
glean information from the inferior, and several ABI-specific
implementations of that interface.  We'd have files named f-abi-ffe.c,
f-abi-sun.c, or whatever.

Similar with Scheme: every Scheme implementation has its own tagging
system, and its own representations for strings, vectors, etc.  Thus,
scm-abi-guile.c, scm-abi-plt.c, etc.