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

Regards,
Loren

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 linker.
-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 (they can't).

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?


--Matt


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