Re: [libstdc++ PATCH] libstdc++ debug mode

[Benjamin Kosnik <bkoz at redhat dot com>]

Some things to think about.

>When testing this patch, be sure to:
>	1) Apply the above-mentioned g++specs patch.
>	2) Rerun autoconf and automake in gcc/libstdc++-v3.
>	3) Pass "--enable-libstdcxx-debug" to configure
>	4) If running the libstdc++ testsuite, add the flag "-D_GLIBCXX_DEBUG" 
>into the flags returned from --build_cxx in the script 
>libstdc++-v3/scripts/testsuite_flags.

For 4, You should just change 

libstdc++-v3/testsuite/libstdc++-v3.dg/dg.exp
DEFAULT_CXXFLAGS "-DDEBUG_ASSERT" 

to

DEFAULT_CXXFLAGS "-D_GLIBCXX_DEBUG"

and in /libstdc++-v3/testsuite/testsuite_hooks.h change

the define of

DEBUG_ASSERT

to 

_GLIBCXX_DEBUG

>For those that don't want to apply the patch and rerun 
>autoconf/automake, there's a patched gcc/libstdc++-v3 available here:
>   http://www.cs.rpi.edu/~gregod/libstdc++-debug-mode-full-20030714.tgz
>Just extract it into a mainline CVS checkout just above the toplevel 
>directory and it will overwrite your libstdc++-v3 directory with the 
>debug-mode version.

That's helpful, thanks. For some reason, stl_algo.h bits don't apply,
but the rest of the patch is fine (and the archive stl_algo.h can be
updated via cvs.)

>Tested on i686-pc-linux-gnu and powerpc-apple-darwin; no regressions on 
>either platform in normal (release) mode or debug mode. ChangeLog 
>follows.

Confirmed.

>	* include/bits/gnu-cxx-utility.h: New.

Eh. For the time being, please just put the __is_null_pointer bits into
the string includes. 

>	* include/bits/debug/support.h: New.
>	* include/bits/debug/vector.h: New.
>	* include/ext/debug/bitset: New.
>	* include/ext/debug/deque: New.

Please don't nest directories in here.

         * include/debug: Add your stuff here.

Also:

 __GLIBCXX_INTERNAL_DEBUG_MAP_H

to

 _GLIBCXX_DEBUG_MAP_H

like the ext directory duplicate headers.

>	* debug/Makefile.am: New.

There's got to be a better solution than this. . . If you don't want to
keep the old, hacky src/Makefile.am rules, that is ok with me, but let's
try to come up with something that's an improvement that doesn't
duplicate so much of src/Makefile.am in the process. Alexandre Oliva
recently suggested looking at the multilib approach, which I believe
libjava uses: can you take a look at that approach please, or quiz him
to see what he means by this?

-benjamin