This is the mail archive of the
mailing list for the libstdc++ project.
Re: Getting Apple's libstdc++ debug mode into the FSF tree
- From: Matt Austern <austern at apple dot com>
- To: Doug Gregor <dgregor at apple dot com>
- Cc: Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>, libstdc++ at gcc dot gnu dot org
- Date: Wed, 16 Jul 2003 10:43:37 -0700
- Subject: Re: Getting Apple's libstdc++ debug mode into the FSF tree
- References: <45A77408-B721-11D7-A166-00039354D67A@apple.com>
On Tuesday, July 15, 2003, at 5:05PM, Doug Gregor wrote:
On Tuesday, July 15, 2003, at 04:35 PM, Loren James Rittle 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.
If there is a change in libraries rather than an extra library, I too
would rather see a formal switch defined to control the selection.
I.e. this would indeed mirror the almost portable, yet defined on
per-port basis, -pthread flag. Humm, I don't see the issue Benjamin
raised since all ports get the same definition of the spec file bits
for picking up libstdc++.
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.
I'd really be against any new code being installed in the C++ library
which is keyed off a macro exposed to the user (_GLIBCXX_DEBUG). We
have been working hard to kill those regions. I would not block such
a change unless the implementations don't mix gracefully (even then,
I'm only one vote of all the library implementators). I.e. if the
user compiles some code with _GLIBCXX_DEBUG and some without and the
mixed code can crash, I'd be completely against the change. I've read
too many PRs from confused users over the years before we rectified
the threading code situation...
Matt was asking about precedent w.r.t. linking against different
libraries based on a macro, and it sounds like -pthreads is it. So in
the next revision of the patch I'll make _GLIBCXX_DEBUG an
implementation detail, and use a formal switch that will (a) define
_GLIBCXX_DEBUG and (b) link against the debug library. Here are some
options for the name of the formal switch:
-lstdc++-debug) Gaby's suggestion
-debug or -debug=c++) Benjamin's comment
-gc++lib) Just a thought...
My opinions on these:
-lstdc++-debug) I think it will confuse users, because they won't
pass it to the compiler thinking it only needs to be passed to the
-debug or -debug=c++) I like it.
-gc++lib) Cute, because -g is already the debug flag and "c++lib" is
another debug mode, but potentially dangerous because people tend to
mix "-g" code with non-"-g" code, and might think they can do so here
I agree with you that -lstdc++-debug and -gc++lib are a little too
cute. I like -debug, and I like -debug=c++ even better because it's
more specific. But I'm also imagining the future of debug modes:
someday we might want to have things like a debug mode for the C
library, or a debug mode that catches array overflows in builtin
arrays, and so on. Do we think we want one switch to control all of
those things, or do we thing we should give users fine-grain control?
If the latter, then we shouldn't choose an overly general name for a
specific case. So maybe -debug=libc++, to make it absolutely explicit
what this flag does?