This is the mail archive of the 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 9:00PM, Loren James Rittle wrote:
Please note that your usage looks like that covered by multilibs.  If
so, the option name must start with `-m' AFAIK.  We have resisted
multilibing libstdc++-v3 over the years by making sure that all new
features and updating of old features which were keyed by macros allow
mix-n-matching at link time without introducing hard-to-debug crashes.
I don't know if multilibing addresses the next issue I will now raise.

Unfortunately, mix-n-match at link time is _very_ hard to support for this problem, because the size of library-defined types (e.g., std::basic_string<...>) changes between debug and production mode. std::basic_string is especially problematic because it is used in many parts of the library. The real killers are compiled virtual functions that return std::basic_string<> instances, such as std::collate<char>::do_transform. Here we have:
1) A function instantiated in libstdc++, so it code cannot change at all between debug and release mode.
2) A return type that changes size between debug and release mode.
3) A virtual function, so users must be able to duplicate the exact signature.

I've made several attempts at mix-and-match linking, none of which has been able to handle this particular case. I've more recently been considering if it is worth providing a 90% debugging solution that does allow mix-n-match linking, because the feature is so often requested.

Some ideas (some practiced, some not):

(1) An external reference to either name A or name B is inserted into
each C++ object file which included any C++ header where it matters
based on presence of macro.  A is only defined in production
libstdc++.  B is only defined in debug libstdc++.  Both names are in
our library implementation namespace.

Unless through some trickery, both libraries get linked in. This is actually quite likely, I think, so we should avoid this option.

(2) An external symbol reference that changes size based on presence
of your macro.  The correctly keyed match is present in the related

We're probably stuck with this option :(

(3) What we did for threading support in the library (here we pay a
small price to use the indirection provided by the gthr abstraction
layer and its dynamic decision of when to use the mutex).

This would be very expensive for the debug mode, because release-mode objects would have to be large enough to store the extra data required in debug mode. For instance, a vector iterator in release mode is generally 4 bytes, but in debug mode it jumps to 20 bytes.

(4) (For grins, I include:) Implement Plan 9 header/linker semantics
in GNU ld and all other linkers ever used with gcc.  That was quite an
innovation IMHO...

:) Doug

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