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

[Doug Gregor <dgregor at apple dot com>]

There's technically a patch in here.

Begin forwarded message:

> From: Doug Gregor <dgregor@apple.com>
> Date: Fri, 11 Jul 2003 11:01:39 -0700
> To: libstdc++@gcc.gnu.org
> Cc: bkoz <bkoz@redhat.com>
> Subject: Getting Apple's libstdc++ debug mode into the FSF tree
>
> We're just about ready to start moving the libstdc++ debug mode into 
> the FSF tree. There is a lot of code in the debug mode, so here's a 
> tentative plan to get things rolling. Comments are _always_ welcome.
>
> 1) Documentation patch: this patch includes the user-level 
> documentation for the libstdc++ debug mode, including usage, 
> configuration/build details, and semantics. This patch comes first 
> (even though, in theory, it should be applied last) to give everyone a 
> feel for the user experience. This patch is attached.
>
> 2) Core debug primitives patch: this will unfortunately be a large 
> patch, because it needs to include all of the safe iterator/container 
> logic. I'll supplement this patch with an overview of the design to 
> try to give everyone a feel for the implementation strategy. A 
> separate patch (say, 2.5) will cover the Makefile/ABI compatibility 
> issues because they do not affect the design.
>
> 3) __gnu_cxx::debug::map debugging container patch: this patch will 
> include the debugging analogue to std::map. This should be used as a 
> reference when reviewing patch #2, because it should show how the 
> debug primitives come together to build a debugging container.
>
> [[ At this point, we'll be able to play with the debugging map 
> implementation. ]]
>
> 4) Configure/Makefile bits to build a libstdc++-debug: the debug mode 
> needs to build a separate version of the library as libstdc++-debug.
>
> 5) g++specs to deal with -lstdc++-debug: this will be a small patch 
> that teaches the driver to deal with the debug library. This is the 
> only change to the compiler that will be absolutely required.
>
> 6) Debug-mode std::map patch: this will be another small patch that 
> turns on replacement of std::map with the debug version when 
> _GLIBCXX_DEBUG is defined.
>
> [[ At this point, we'll be able to take a program and compile it 
> either in debug mode or normal "release" mode; std::map will be the 
> debuggable version when in debug mode and will be the untouched, 
> normal version in release mode. ]]
>
> 7) Patches to make "make check" work for running the testsuite under 
> debug mode.
>
> 8) Debugging container patches: this will be a serious of patches that 
> implement debugging containers for each of the standard (and some of 
> the extension) containers. Each patch will supply:
> 	a) the debug version of std::foo
> 	a) the header ext/debug/foo giving release/debug-mode acces to the 
> debug container __gnu_cxx::debug::foo
> 	b) the necessary hooks to allow the debug version of std::foo to take 
> over when in debug mode
> All of these patches will use the same ideas as std::map, so the debug 
> container methodology should be agreed upon by now and the only things 
> to review per-container will be the debug semantics and the particular 
> container interface.
>
> 9) Algorithm/component precondition checks: this will be a series of 
> patches (one per file) that will add precondition checks to, e.g., 
> standard algorithms, components, and iterators that we don't bother 
> wrapping. For instance, checking that std::lower_bound receives an 
> appropriately sorted sequence.
>
> 10) Better error message reporting: we'll see the use of this 
> error-reporting mechanism, but they'll be hidden from the compiler 
> with preprocessor macros. This patch will flip the switch to use a 
> different error-reporting mechanism that gives much more information 
> about errors found by the debug mode.
>
> And again, any comments on this plan would be greatly appreciated. 
> It's a lot of code to review, but I'll try to make the review as 
> painless as is possible.
>
> One question before I finish: would it help if I created one big 
> ball-o-wax patch now, in advance of the smaller patches, so that those 
> daring enough can try the whole of the debug mode first? It may help 
> when reviewing the smaller patches, although I believe the structure 
> of the above plan will give the same effect.
>
> Thank you. And without further delay, the documentation patch...
>
> 	Doug
>
>

Attachment: debug_docs.patch
Description: Binary data