Getting Apple's libstdc++ debug mode into the FSF tree

[Doug Gregor]

On Tuesday, July 15, 2003, at 9:00PM, Loren James Rittle wrote:
> Please note that your usage looks like that covered by multilibs.  If
> so, the option name must start with `-m' AFAIK.  We have resisted
> multilibing libstdc++-v3 over the years by making sure that all new
> features and updating of old features which were keyed by macros allow
> mix-n-matching at link time without introducing hard-to-debug crashes.
> I don't know if multilibing addresses the next issue I will now raise.

Unfortunately, mix-n-match at link time is _very_ hard to support for 
this problem, because the size of library-defined types (e.g., 
std::basic_string<...>) changes between debug and production mode. 
std::basic_string is especially problematic because it is used in many 
parts of the library. The real killers are compiled virtual functions 
that return std::basic_string<> instances, such as 
std::collate<char>::do_transform. Here we have:
	1) A function instantiated in libstdc++, so it code cannot change at 
all between debug and release mode.
	2) A return type that changes size between debug and release mode.
	3) A virtual function, so users must be able to duplicate the exact 
signature.

I've made several attempts at mix-and-match linking, none of which has 
been able to handle this particular case. I've more recently been 
considering if it is worth providing a 90% debugging solution that does 
allow mix-n-match linking, because the feature is so often requested.

> Some ideas (some practiced, some not):
>
> (1) An external reference to either name A or name B is inserted into
> each C++ object file which included any C++ header where it matters
> based on presence of macro.  A is only defined in production
> libstdc++.  B is only defined in debug libstdc++.  Both names are in
> our library implementation namespace.

Unless through some trickery, both libraries get linked in. This is 
actually quite likely, I think, so we should avoid this option.

> (2) An external symbol reference that changes size based on presence
> of your macro.  The correctly keyed match is present in the related
> library.

We're probably stuck with this option :(

> (3) What we did for threading support in the library (here we pay a
> small price to use the indirection provided by the gthr abstraction
> layer and its dynamic decision of when to use the mutex).

This would be very expensive for the debug mode, because release-mode 
objects would have to be large enough to store the extra data required 
in debug mode. For instance, a vector iterator in release mode is 
generally 4 bytes, but in debug mode it jumps to 20 bytes.

> (4) (For grins, I include:) Implement Plan 9 header/linker semantics
> in GNU ld and all other linkers ever used with gcc.  That was quite an
> innovation IMHO...

:)
	Doug