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

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

In article <45A77408-B721-11D7-A166-00039354D67A@apple.com>,
Doug Gregor<dgregor@apple.com> writes:

Hi Doug,

> Matt was asking about precedent w.r.t. linking against different

I agree with Matt on the quirkiness of the macro-keyed linker thingy.
FYI, it is possible that the driver would have canonicalized the
command line but note that users could have provided '-DX' or '-D X'
to define macro X.

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

Thank you for taking time to rework that aspect.

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

> Anyone have a strong preference on these? Or any other flag names?

I have no strong preference on the exact name of the option.  However...

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.

Can you do anything to ensure that people that attempt to link code
compiled with the option against code compiled without the option will
get an error message from the linker.  It appears to me that you are
about to propose to commit a change of the precise form that will
cause us grief in terms of future user problem reports.

This may look like a high bar to now pass but FYI the collective team
worked for a long time to remove that exact failure mode from the
threading support in the C++ library.

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.

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

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

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

Regards,
Loren