MT string, to do next

[ncm@cantrip.org]

Attn: Ulrich
Re: MT string

Once we get the apparatus into bits/*string*, we need to do more 
munging in the build-and-link system.  It will involve complicated 
ld and ldso hackery.

First, the problem:  

When normal distributions (e.g. Debian & Red Hat) build libstdc++, 
they don't build with 686 flags, and they don't build with Pentium 
flags, and they don't even build with _486_ flags.  They build for a 
generic 386 box.  

The 386 doesn't have a "lock" instruction, and will trap if it sees it.
Our current config/cpu/i386/atomicity.h erroneously assumes that we are 
compiling for a 486 or better.  As a result, libstdc++ string code will 
fail on a 386 (and on my NexGen P110, too).  

Although the default x86 build must assume a 386 if not told otherwise, 
multithreading must work right when running it, anyhow, even on an SMP 
686 box.  You can't get that behavior with inlines.  Therefore, the 
configure script must choose a "generic" implementation which is built 
_non-inline_.  The generic functions defined should do ordinary increment 
and decrement operations, which are not interruptible on a CISC and 
therefore should be sufficient for a UP x86 machine.  

When actually running on an SMP machine (or a 486 or better, if that's 
easier), though, the same calls should dynamically link to another 
implementation which uses the lock instruction.  While calling into
a shared library is slower than doing the instructions inline, it at
least works correctly.  Working correctly is important.

The header file seen by client code built against the library should
vary according to the build target.  Code built specifically for a 
486 or better should see inline definitions, instead.  Then, the 
client code will contain the lock instructions directly, and ignore 
the non-inline implementations.  If not specifically compiled for a 
486 or better, the non-inline declarations lead to the correct shared
library.

Clear?  Have I got it right, Ulrich?  

The mechanics of getting the right object code linked at runtime
involves ld and ldso trickery I haven't learned how to do yet,
but would like to learn.

[Note: This is all made more complicated yet because the functions 
that actually use the atomicity.h functions, _Rep::_M_dispose() and 
_Rep::_refcopy() are themselves inline, as are various functions that
(in turn) call them.  Furthermore, they are all template functions.]

Maybe an alternative approach would be better.  Same problem, different
solution.  Ideas?

Nathan Myers
ncm@nospam.cantrip.org