This is the mail archive of the
mailing list for the libstdc++ project.
Getting Apple's libstdc++ debug mode into the FSF tree
- From: Doug Gregor <dgregor at apple dot com>
- To: libstdc++ at gcc dot gnu dot org
- Cc: bkoz <bkoz at redhat dot com>
- Date: Fri, 11 Jul 2003 11:01:39 -0700
- 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
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
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
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
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...
Description: Binary data