Re: Configuration patches to handle threading and general tuning issues

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

Hello Dave,

Thanks for the feedback.  I await HPUX results when possible. 

>> libstdc++-v3 was completely rebuilt and reinstalled (with a little
>> help to move gthr*.h files by hand) but only informal testing has
>> commenced so far, no full bootstrap, no full regression test.
>> However, I did check to ensure all the right macros are appearing
>> where they should under this ../gcc/gthr*.h-based configuration style.

OK, I am now reviewing full bootstrap/check cycle results for
i386-*-freebsd*.  I saw more failures without -pthread because
__cxa_get_globals had a code path that attempted to use a weak pointer
with a value of NULL.  Replacement for the patch to libsupc++ is
included below (and I think the change is alright for platforms that
install fake thread routines when the real ones are not linked in like
Solaris and Linux? do).  With it I see these libstdc++-v3 and g++
results (rebuilt library only after patching only libsupc++/eh_globals.cc):

Running target unix
XPASS: 26_numerics/c99_classification_macros_c.cc (test for excess errors)
[14 g++.dg/vtgc1.C XPASS]
XPASS: g++.other/crash27.C (test for excess errors)

Running target unix/-pthread -fpic
XPASS: 26_numerics/c99_classification_macros_c.cc (test for excess errors)
ERROR: g++.dg/vtgc1.C: error executing dg-final: [file "vtgc1.s" not found]
FAIL: g++.eh/badalloc1.C  Execution test [see below]
FAIL: g++.other/crash18.C (test for excess errors) [-fvtable-gc -fpic failure
						    unrelated to this patch]
XPASS: g++.other/crash27.C (test for excess errors)

On my platform, g++.eh/badalloc1.C is a new failure but it is correct
since the code path in libstdc++-v3/libsupc++/eh_globals.cc is now
using the gthr threading primitives and malloc() to get memory on a
per-thread basis to handle EH context instead of misusing the global
memory as before Dave observed that code was being miscompiled (I had
only ever noticed that the STL configuration itself was munged).

Unfortunately, this does mean that a QoI issue that Nathan Sidwell
worked to remove last year related to C++ EH and multi-threading has
now resurfaced...

But it is *far* more important to correctly allocate EH contexts in
the threaded situation than to risk EH state corruption when multiple
threads concurrently process exceptions.

However, that testsuite doesn't really check whether EH is working
across threads...

> I did a complete bootstrap and check with unix/-pthread, unix/-fPIC
> and unix/ under i686 linux.  I am down to two v3 FAILs for all modes.

> The v3 FAILs are:

> FAIL: 22_locale/codecvt_unicode_char.cc execution test
> FAIL: 22_locale/codecvt_unicode_wchar_t.cc execution test

> There are no g++ regressions either.  I am going to give it a whirl
> under hpux.

If this technique basically works on hpux, then will you support this
direction to fix/robustify threading support in libstdc++-v3? ;-)

> Excellent work!

Thanks, you did half of the hard work!  I am fixing the remaining
known issues with what I posted Thursday morning.  I will roll another
complete patch against the mainline and post it before leaving for a
long weekend.  If no one complains by Tuesday, I think we should put
it on the mainline with the hopes of moving it to 3.0 branch after
that.

Index: libsupc++/eh_alloc.cc
===================================================================
RCS file: /cvs/gcc/egcs/libstdc++-v3/libsupc++/eh_alloc.cc,v
retrieving revision 1.2
diff -c -r1.2 eh_alloc.cc
*** eh_alloc.cc	2001/04/12 07:47:34	1.2
--- eh_alloc.cc	2001/05/25 15:44:47
***************
*** 35,41 ****
  #include <cstring>
  #include <limits.h>
  #include "unwind-cxx.h"
! #include "gthr.h"
  
  using namespace __cxxabiv1;
  
--- 35,42 ----
  #include <cstring>
  #include <limits.h>
  #include "unwind-cxx.h"
! #include "bits/c++config.h"
! #include "bits/gthr.h"
  
  using namespace __cxxabiv1;
  
Index: libsupc++/eh_globals.cc
===================================================================
RCS file: /cvs/gcc/egcs/libstdc++-v3/libsupc++/eh_globals.cc,v
retrieving revision 1.1
diff -c -r1.1 eh_globals.cc
*** eh_globals.cc	2001/03/28 11:04:50	1.1
--- eh_globals.cc	2001/05/25 15:44:47
***************
*** 29,36 ****
  
  
  #include <exception>
  #include "unwind-cxx.h"
! #include "gthr.h"
  
  using namespace __cxxabiv1;
  
--- 29,38 ----
  
  
  #include <exception>
+ #include <cstdlib>
  #include "unwind-cxx.h"
! #include "bits/c++config.h"
! #include "bits/gthr.h"
  
  using namespace __cxxabiv1;
  
***************
*** 90,113 ****
      return &globals_static;
  
    if (use_thread_key < 0)
!     get_globals_init_once ();
  
    g = (__cxa_eh_globals *) __gthread_getspecific (globals_key);
    if (! g)
      {
!       static __gthread_once_t once = __GTHREAD_ONCE_INIT;
! 
!       // Make sure use_thread_key got initialized.  Some systems have
!       // dummy thread routines in their libc that return a success.
!       if (__gthread_once (&once, eh_threads_initialize) != 0
! 	  || use_thread_key < 0)
! 	{
! 	  use_thread_key = 0;
! 	  return &globals_static;
! 	}
!       
!       if ((g = malloc (sizeof (__cxa_eh_globals))) == 0
! 	  || __gthread_setspecific (eh_context_key, (void *) g) != 0)
          std::terminate ();
        g->caughtExceptions = 0;
        g->uncaughtExceptions = 0;
--- 92,110 ----
      return &globals_static;
  
    if (use_thread_key < 0)
!     {
!       get_globals_init_once ();
! 
!       // Make sure use_thread_key got initialized.
!       if (use_thread_key == 0)
! 	return &globals_static;
!     }
  
    g = (__cxa_eh_globals *) __gthread_getspecific (globals_key);
    if (! g)
      {
!       if ((g = (__cxa_eh_globals *) std::malloc (sizeof (__cxa_eh_globals))) == 0
! 	  || __gthread_setspecific (globals_key, (void *) g) != 0)
          std::terminate ();
        g->caughtExceptions = 0;
        g->uncaughtExceptions = 0;