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

Doug Gregor
Fri Jul 11 21:46:00 GMT 2003

On Friday, July 11, 2003, at 2:07PM, Benjamin Kosnik wrote:

>> 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.
> This is fine for the time being.
> Long-term, the thought elegantly expressed when --enable-debug went in
> is that maybe a -debug=c,c++ flag would link in the correct debug
> libraries automatically, much the way -pthread operates. Thus, on linux
> g++ -debug
> would link in
> /usr/lib/debug/libc
> (prefix)/lib/debug/libstdc++
> Anyway. Would be nice, huh?
> However, because the configure/build issues for debug target libraries
> have not been standardized, this seems unlikely in the near term, and
> your approach seems ok. I still like the lib/debug/libstdc++ bits
> better, but since we can't do the above, it doesn't really matter.

I had actually considered using something like -gc++lib, but thought  
that I would start out on the path of least resistance. In any case, I  
would be thrilled to see a "-debug" flag that just does the right  
thing. FWIW, -D_GLIBCXX_DEBUG actually adds "-lstdc++-debug" instead of  
"-lstdc++",  but I don't mention it in the documentation because then  
people will forget to pass -lstdc++-debug when linking :)

>> 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.
> I'm interested in this, but suppose I might as well just wait to see
> your patch.

It essentially consists of lots of annotations at the checking sites.  
Nothing brilliant, just lots of typing, including:
	1) file/line information
	2) debug error message
	3) parameters and their formal names

Since we have extra information about iterators and containers, that's  
part of the output. For instance, here's the error message given when  
we try to insert into one container with an iterator position in  
another container:

     error: attempt to insert into container with an iterator from a
     different container.

Objects involved in the operation:
sequence "this" @ 0xbffffc90 {
   type = Ss;
iterator "__p" @ 0xbffffd00 {
   type =  
e_basic_stringIcSt11char_traitsIcESaIcEEEESsEE (mutable iterator);
   state = dereferenceable (start-of-sequence);
   references sequence with type `Ss' @ 0xbffffcb0

We can easily make it look nicer (e.g., by demangling those type  
names), but the point is that the information is there to present in a  
better way. A backtrace would also be quite helpful, if we can do it  

>> 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.
> To tell you the truth, I'd like to see this patch first, and reserve  
> the
> right to suggest implementing it all in one bite.

It won't be today (I need to catch a flight...), but early next week  
I'll have a full patch ready.


More information about the Libstdc++ mailing list