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

[Loren James Rittle]

Hi again Doug,

In article <192F6496-B7A7-11D7-9782-00039354D67A@apple.com>,
Doug Gregor<dgregor@apple.com> writes:

> Unfortunately, mix-n-match at link time is _very_ hard to support for 
> this problem, because the size of library-defined types (e.g., [...]

You made the case why mix-n-match would be hard to support.  Of course
that is OK, if it works best to not support it.

>> (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 :(

If you are willing to add this feature (or already have it) such that
a warning/error is produced with standard linkers, then I think you
have tamed any reservations I might have about this change.  I
monkeyed around for longer than I will now admit trying to get (2)
actually working.  If (1) is unacceptable, how about (1.5) (or as
further refined by all of us; all names/namespaces/warning text are
open for change):

// TRANSLATION UNIT 1 (includes comments on where stuff really goes in library)

// This section visible from c++config.h:
extern "C" int __glibcxx_mlo_production;
extern "C" int __glibcxx_mlo_debug;

// This subsection abstracted from FreeBSD src, original author unknown:
#ifdef __ELF__
#define __warn_references(sym,msg) \
        __asm__(".section .gnu.warning." #sym); \
        __asm__(".asciz \"" msg "\""); \
        __asm__(".previous")
#else
#define __warn_references(sym,msg) \
        __asm__(".stabs \"" msg "\",30,0,0,0"); \
        __asm__(".stabs \"_" #sym "\",1,0,0,0")
#endif
// EOSubS

#if __GLIBCXX_DEBUG
namespace { int __glibcxx_mlo_user (void) { return __glibcxx_mlo_production; } }
#else
namespace { int __glibcxx_mlo_user (void) { return __glibcxx_mlo_debug; } }
#endif
// EOS

// This section only seen while building library (e.g. src/globals.cc):
int __glibcxx_mlo_production;
int __glibcxx_mlo_debug;

#if __GLIBCXX_DEBUG
__warn_references (__glibcxx_mlo_debug,
		   "warning: conflict of debug options created ODR violation");
#else
__warn_references (__glibcxx_mlo_production,
		   "warning: conflict of debug options created ODR violation");
#endif
//EOS

main(){}

// TRANSLATION UNIT 2 (faked to allow testing)

extern "C" int __glibcxx_mlo_production;
extern "C" int __glibcxx_mlo_debug;

namespace { int __glibcxx_mlo_user (void) { return __glibcxx_mlo_debug; } }

// TRANSLATION UNIT 3 (faked to allow testing)

extern "C" int __glibcxx_mlo_production;
extern "C" int __glibcxx_mlo_debug;

namespace { int __glibcxx_mlo_user (void) { return __glibcxx_mlo_production; } }

Attempt to compile and link T1 alone, T1&T2, T1&T3, T1&T2&T3 in light
of various command line settings of __GLIBCXX_DEBUG.  I believe that
the ODR violation is reported with zero run-time and near-zero space
overhead.

>> (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.

OK, got it.