Additional commentary on PATCH: Configure libstdc++-v3 against gthr.h

[Loren James Rittle]

After bootstrapping the "final" version of the patch (only final in
that I think it might be close to applying to mainline), here are some
results not found in the `make check' results.  But first, there is
one `make check' regression observed on some platforms:

FAIL: g++.eh/badalloc1.C  Execution test

(It may fail on any platform where the thread routines may try to
 allocate memory.  The only reason it wasn't failing before this
 patch is because we really weren't handling threading properly.)

For at least the platforms I checked, the `make check' was run so that
all tests were linked (and then run) both against the thread routines
and not against them.

Using the first simple timing test (which was originally given as a
memory leak test) from: http://gcc.gnu.org/ml/libstdc++/2001-05/msg00384.html

Compile it once (with no special thread-related options):

/usr/local/beta-gcc/bin/g++ -O3 -c l.C

Link and run it twice (once against pthread routines and once without them):

/usr/local/beta-gcc/bin/g++ -O3 -R/usr/local/beta-gcc/lib -pthread l.o
time a.out
   176r   173.8u     1.8s       a.out

/usr/local/beta-gcc/bin/g++ -O3 -R/usr/local/beta-gcc/lib l.o
time a.out
    63r    57.7u     1.0s       a.out

(Both cases checked under gdb to ensure that mutex locking was
 correct.  I did this by setting a breakpoint on main, running,
 setting a breakpoint on pthread_mutex_lock, continuing, etc.  To
 really get a feel, I also checked the binary produced with '-g -O0'.)

Notice how the decision to pay the overhead for mutex locking is
basically deferred to link-time and/on run-time based on the value of
a weak symbol instead of compile-time.  No special compilation flags
were needed anymore.  Thus, this is now working just as EH threading
support in libgcc.a (C++ EH now in libsupc++.a).

(Note, you may need to provide the correct option or library in place
 of -pthread, if it is different for your platforms.)

(Aside, there appears to be a linker bug on where weak symbols don't
 work properly with static libraries.  This has been reported to Phil,
 the release manager for binutils 2.11.1?, who just requested such
 feedback.)

The second test from that e-mail also runs in the same time as
reported (that test requires the thread library).

How any of these tests get into the testsuite is still beyond me.  Any
test would appear to require some non-portable thread code.

Unfortunately, this is the only thing close to an automatic and
portable test that I can generate at the moment (and I have no idea
how this would get hooked into dejagnu):

g++ -E l.C | grep 'void _M_acquire_lock' | grep -q __gthread_mutex_lock
g++ -E -dM l.C | grep __STL_MUTEX_INITIALIZER|grep -q __GTHREAD_MUTEX_INIT

If both pipelines exit with 0 status, then threading should work with
STL as defined by SGI for the platform without any special user
intervention (other than the linking step, they already know how to do
in order to find pthread_create or whatever).  If only the first exits
with 0 status, then the user should get compile-time warnings
explaining that certain objects created in the system need to have a
method run on them from main(), etc before any other STL calls are
made (yes, this should be automated if we can under g++ even if not
specified by C++ standard - I don't know how to do this yet).  If the
first pipeline exits with non-0 status, then (1) something broke on
the port; or (2) something broke in general.

Regards,
Loren