Re: Solaris 2.6 EH failures

Re: Solaris 2.6 EH failures

[Teemu Torma]

Jim Wilson <wilson@cygnus.com> writes:

> The problem is a bad interaction with the thread support.  Solaris 2.6
> has POSIX thread support, so configure chooses to use that one.  If you
> then run a testcase that uses EH, we end up in an infinite loop in
> eh_context_initialize, because pthread_once returns zero but does not do
> anything.  If you compile that testcase with -lpthread, then it works fine.
> 
> It seems that if you don't use -lpthread, then the pthread function calls
> are mapped to a helper function named _return_zero that does nothing but
> return zero.  This is perhaps a feature of the Solaris shared library support.
> Maybe if you call a function that doesn't exist it gives you _return_zero?

Solaris libc seems to have all pthread functions defined; it does not
seem to be a general feature.  

> This seems to work though perhaps there are better solutions.  I haven't
> looked at the thread support in any detail as yet.
> 
> Fri Mar  6 18:00:18 1998  Jim Wilson  <wilson@cygnus.com>
> 
> 	* libgcc2.c (eh_context_initialize): Check get_eh_context instead of
> 	return value to see if __gthread_once worked.

I posted a similiar fix in http://www.cygnus.com/ml/egcs/1998-Jan/0123.html .
It fixes also some inconsistent return values and checking of them.

Teemu

Re: Solaris 2.6 EH failures

[Jim Wilson]

	I posted a similiar fix in http://www.cygnus.com/ml/egcs/1998-Jan/0123.html .
	It fixes also some inconsistent return values and checking of them.

Thanks for pointing it out.  I hadn't realized that you already had a fix for
the problem.  Your patch looks good.  I installed it.

Jim

Re: Solaris 2.6 EH failures

[Andrey Slepuhin]

On 11-Mar-98 David Edelsohn wrote:
>>>>>> Jim Wilson writes:
> 
> Jim> If using POSIX thread support under Solaris 2.6, we either need to
> ensure
> Jim> that -lpthread is always linked in with libgcc.a, or else we need to
> Jim> fix eh_context_initialize to handle this failure mode.
> 
>       This is an issue for AIX as well.  AIX 4 supports pthreads if
> compiled with the -mthreads commandline option (which defines a special
> macro and links with re-entrant versions of libraries and a special
> startup file).  Unlike Solaris, EGCS currently does not assume that AIX
> supports threads and the thread support in EH and ObjC are not utilized.
> Threads is not the default in AIX 4.1 or 4.2, but the variants may have
> been removed in AIX 4.3.

There is a real pain to install egcs with thread support correctly.
I work much with threads on AIX and Linux and both egcs targets
have no thread support by default. I don't understand why threads
support is not enabled, because many applications claim it.
I also don't understand why egcs uses different compiler options
to enable threads support on AIX and Linux.

>       PowerPC already has too many multilib variants so I would like to
> avoid this additional combinatorial option.  However, I'm not quite sure
> how to handle this or what users want.

I agree. On my AIX box I manually disable CPU-specific multilib targets
and add thread-safe target instead. What I really want is custom multilib
configuraton (i.e. something like this: --enable-threads --disable-cpu
should give me all what I need).

Regards,
Andrey.

Re: Solaris 2.6 EH failures

[Shigeya Suzuki]

>> If a user actually wants the thread support to work, then they will add
>> the -lpthread themselves, so a workaround in libgcc2.c should be OK I think.

I took sources via CVS repository (Mar 11 15:33 JST) and applied the
patch, bootstrap, and run check-g++.

Yep. it dramatically improved the test result, comparable to following 
result

>>From: Manfred Hollstein <manfred@s-direktnet.de>
>>Subject: CVS egcs-980309: results on sparc-sun-solaris2.5.1 haifa disabled
>>Date: 	Tue, 10 Mar 98 16:36:53 +0100

Glad to see this result. I'll post whole full test result later.

Shigeya Suzuki

------------------------------

                === g++ Summary ===

# of expected passes            3718
# of unexpected failures        3
# of unexpected successes       1
# of expected failures          75
# of untested testcases         6
/local/src/egcs/snap/build/gcc/testsuite/../xgcc version egcs-2.91.13 980308 (gcc-2.8.0 release)

Re: Solaris 2.6 EH failures

[David Edelsohn]

>>>>> Jim Wilson writes:

Jim> If using POSIX thread support under Solaris 2.6, we either need to ensure
Jim> that -lpthread is always linked in with libgcc.a, or else we need to
Jim> fix eh_context_initialize to handle this failure mode.

	This is an issue for AIX as well.  AIX 4 supports pthreads if
compiled with the -mthreads commandline option (which defines a special
macro and links with re-entrant versions of libraries and a special
startup file).  Unlike Solaris, EGCS currently does not assume that AIX
supports threads and the thread support in EH and ObjC are not utilized.
Threads is not the default in AIX 4.1 or 4.2, but the variants may have
been removed in AIX 4.3.

	PowerPC already has too many multilib variants so I would like to
avoid this additional combinatorial option.  However, I'm not quite sure
how to handle this or what users want.

	I am not quite sure where EGCS is trying to head with thread
support. 

Thanks,
David

Solaris 2.6 EH failures

[Jim Wilson]

The problem is a bad interaction with the thread support.  Solaris 2.6
has POSIX thread support, so configure chooses to use that one.  If you
then run a testcase that uses EH, we end up in an infinite loop in
eh_context_initialize, because pthread_once returns zero but does not do
anything.  If you compile that testcase with -lpthread, then it works fine.

It seems that if you don't use -lpthread, then the pthread function calls
are mapped to a helper function named _return_zero that does nothing but
return zero.  This is perhaps a feature of the Solaris shared library support.
Maybe if you call a function that doesn't exist it gives you _return_zero?

If using POSIX thread support under Solaris 2.6, we either need to ensure
that -lpthread is always linked in with libgcc.a, or else we need to
fix eh_context_initialize to handle this failure mode.

If a user actually wants the thread support to work, then they will add
the -lpthread themselves, so a workaround in libgcc2.c should be OK I think.

This seems to work though perhaps there are better solutions.  I haven't
looked at the thread support in any detail as yet.

Fri Mar  6 18:00:18 1998  Jim Wilson  <wilson@cygnus.com>

	* libgcc2.c (eh_context_initialize): Check get_eh_context instead of
	return value to see if __gthread_once worked.

Index: libgcc2.c
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/libgcc2.c,v
retrieving revision 1.26
diff -p -r1.26 libgcc2.c
*** libgcc2.c	1998/02/13 05:40:25	1.26
--- libgcc2.c	1998/03/07 01:59:57
*************** eh_context_initialize ()
*** 3132,3142 ****
  #if __GTHREADS
  
    static __gthread_once_t once = __GTHREAD_ONCE_INIT;
!   if (__gthread_once (&once, eh_threads_initialize) == -1)
!     {
!       /* Use static version of EH context. */
!       get_eh_context = &eh_context_static;
!     }
  
  #else /* no __GTHREADS */
  
--- 3132,3144 ----
  #if __GTHREADS
  
    static __gthread_once_t once = __GTHREAD_ONCE_INIT;
!   __gthread_once (&once, eh_threads_initialize);
! 
!   /* If it failed, use static version of EH context.  We can't check the
!      return value, because Solaris 2.6 gets this wrong if linking without
!      -lpthreads.  */
!   if (get_eh_context == eh_context_initialize)
!     get_eh_context = &eh_context_static;
  
  #else /* no __GTHREADS */