This is the mail archive of the mailing list for the libstdc++ project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Attachment: debug_docs.patch
Description: Binary data

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]