This is the mail archive of the libstdc++@gcc.gnu.org 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]

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



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

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:

/Volumes/Data/Projects/FSF/Install/include/c++/3.4/bits/debug/ basic_string.h:394:
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 = NSt7__debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPcSt21_Releas 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 portably...

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.


Doug


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