PATCH: Re: eh_globals.cc compilation errors with -threads under hpux 10.20

[Loren James Rittle]

I am responding to three separate e-mails in the order that makes
sense to read my responses...

Summary: In terms of the big picture, I now agree with most of what
Dave has posted since I complained about his first patch.  Sorry, for
taking a while longer to get up to speed on these issues.

Under the assumption (based on Phil's comment that he punted ;-) that
libstdc++/include/bits/c++config may now be further adjusted to
address threading configuration issues, please know that I no longer
wish you to refrain from installing parts of your patch on the
mainline (with the further assumption that they will be moved to the
3.0 branch after we complete all other configuration changes needed to
not break ports).  Additional commentary on parts of your patch now
that I'm up to speed:

- I still think you need to rework the part that adds THREADS_FLAGS
  and sets it to -pthread since I think we have established that no
  convention on that flag exists yet and (putting my release manager
  hat on:) I don't think that Mark will look kindly towards a
  mega-configuration patch which affects almost every port this close
  to the 3.0 release.

- libstdc++-v3/config/threads-posix.h part is completely OK by me.

- Regarding the patch to libsupc++/eh_globals.cc, I don't know enough
  yet (given that eh_threads_initialize seems to no longer exist, I
  agree that a part of your patch is needed).  It seems that the root
  problem is that when EH support for C++ was moved (or ar least a
  portion was moved) from ../../gcc to a location under libstdc++-v3
  "we" forgot to ensure that HAVE_GTHR_DEFAULT has to be defined, if
  indeed it was configured that way in ../gcc, in order to properly
  include gthr.h and thus get gthr_default.h and get __GTHREAD
  properly defined, etc.

Regarding this last comment, I would like to make a patch to fix the
root problem of misusing ../gcc/gthr.h.  I have known we were doing
something funky for a while, but I wasn't hot on the problem until
last week.  Since you have effectively done half the work David, would
you like to be a co-author of the patch?  We can start by me sending
you (and the list) a working draft.  My proposed patch to fix the root
configuration problem will be the next transmission to you.

In article < 200105231724.NAA20082@hiauly1.hia.nrc.ca >,
"John David Anglin" <dave@hiauly1.hia.nrc.ca> writes:

> I also have been doing a little digging trying to find out if _PTHREADS
> is used by pthreads and have been unable to find any use of this symbol.
> It seems that it was introduced within gcc to control the loading of
> the correct thread file by gthr.h.

I agree completely with your analysis (and if this is what you meant
by "compiler define" all along, then I now completely understand that
as well).  _PTHREADS is a gcc invention that is used to override
taking either gthr-default.h or gthr-single.h.

It appears that few ports use it thus... libstdc++-v3 should not be
using it unless the usage convention is expanded to encompass most/all
pthread-capable ports.

>> ; grep PTHREADS `{find . -type f}
>> ./i386/sol2.h:  %{pthreads:-D_REENTRANT -D_PTHREADS} \
>> ./sh/linux.h:   %{pthread:-D_REENTRANT -D_PTHREADS}"
>> ./sparc/sol2.h:%{pthreads:-D_REENTRANT -D_PTHREADS} \

> I don't have access to any of these so I can't confirm if these systems
> actually need _PTHREADS for anything other than gthr.h.

I do have access to a Solaris 2.7 machine.  Running this command:

; find /usr/include -type f -exec grep _PTHREADS '{}' /dev/null \;

produces no output, thus the system headers do not depend on that
symbol.  Further proof that you are right on what we now understand.

If I run that command on my FreeBSD box, the only hits are in
/usr/include/g++ (and further confined to the old STL header files).

> _REENTRANT is used to get reentrant errno.h defines.

This is true on some systems (Solaris 2.7 uses that symbol in its
system headers).  I get a reentrant errno.h with or without that
symbol.  Thus again, libstdc++ should make no threading assumptions
based on that symbol as well (i.e. it make be needed by the port's
system headers, but libstdc++ shouldn't change behavior based on that
symbol) unless it is defined in a consistent manner dictated by a new
gcc convention.

> eh_globals.cc and eh_alloc.cc include gthr.h.  For gthr.h to include
> the correct thread definitions, the following have to be correctly defined
> or not defined as the case may be:

Fully agreed.

> _PTHREADS
> _DCE_THREADS
> _SOLARIS_THREADS

Commentary: the symbols above allow the user to dynamically select an
override of the thread package assigned to be known as gthr_default.h

I don't know that any library code or header should have been defining
any of them.

> HAVE_GTHR_DEFAULT

Yup, this symbol should be defined before including gthr.h, if and
only if, ../gcc/Makefile defined it (in other words, libgcc.a was
built with it defined).

> SUPPORTS_WEAK

I see no way to correctly learn the setting of this define from the
gcc source tree unless we use an autoconfig test.  Port config files
under gcc/gcc/config define ASM_WEAKEN_LABEL and then
gcc/gcc/defaults.h uses it to define SUPPORTS_WEAK correctly.

However, for any code compiled by g++, we might be able to use
__GXX_WEAK__, if we can get agreement that it will continue to exist

> GTHREAD_USE_WEAK

The configure.in in libobjc has this wonderful construct to ensure
that HAVE_GTHR_DEFAULT gets set as it was in ../gcc:

AC_CACHE_CHECK([for gthread cflags],objc_cv_gthread_flags,
[if test -f "$r"/gcc/Makefile
then
  objc_cv_gthread_flags=`grep \^GTHREAD_FLAGS "$r"/gcc/Makefile | awk -F= '{ pri
nt $2 }'`
else
  AC_MSG_ERROR([not found])
fi])
GTHREAD_FLAGS=$objc_cv_gthread_flags
AC_SUBST(GTHREAD_FLAGS)

The Makefile.in adds GTHREAD_FLAGS to the set of flags used to compile
the entire tree.  We should consider doing the same.  I do understand
that this change may not allow libstdc++-v3 to built as an independent
project.  But how did it after we started to include gthr.h?

I'm not going to say that is perfect, but it has been working over
there to allow them to correctly use gthr.h.  We need it or an
improvement in libstdc++-v3.

In article < Pine.SOL.3.91.1010523095823.12622D-100000@taarna.cygnus.com >,
Benjamin Kosnik <bkoz@redhat.com> writes:

>> > I didn't notice this problem but it further confirms that threads-posix.h
>> > shouldn't muck with a define that is normally a compiler define.

> I now agree with this postion: threads-posix.h shouldn't re-define 
> _PTHREADS or _REENTRENT.

I am rapidly becoming sold on the idea as well.  I really would want
to make libstdc++-v3 obtain thread support from gcc/gthr.h properly.

I now see that defining _PTHREADS was a kludge to get gthr-posix.h
since we didn't setup to include gthr-default.h if it was created in
../gcc.

>> BTW, none of this is to say that I would not support making gcc
>> declare _GCC_PTHREADS (and _PTHREADS and other symbols, if required
>> for a given port's headers) when -pthread was provided by the user and
>> making -pthread an option for all POSIX thread-capable ports.  I have
>> supported basically that position for years.  Who do we have to
>> convince?

> I think you just have to supply a patch.

OK, this is a mega-configuration patch for files under gcc/gcc/config.
This will not be accepted before 3.0 is released nor should it.

In article < 200105231750.NAA20250@hiauly1.hia.nrc.ca >,
"John David Anglin" <dave@hiauly1.hia.nrc.ca> writes:

>> eh_globals.cc and eh_alloc.cc include gthr.h.  For gthr.h to include
>> the correct thread definitions, the following have to be correctly defined
>> or not defined as the case may be:

> This is what currently happens under i686 linux compiling eh_globals.cc:

> # 34 "../../../../libstdc++-v3/libsupc++/eh_globals.cc" 2
> # 1 "../../../../gcc/gthr.h" 1
> # 102 "../../../../gcc/gthr.h"
> # 1 "../../../../gcc/gthr-single.h" 1
> # 34 "../../../../gcc/gthr-single.h"
> typedef int __gthread_mutex_t;

Yikes! OK, I now agree that I see this bad behavior on BSD as well.

> We got the wrong thread model.  We should have got gthr-default.h
> which is a link to gthr-posix.h.  If _PTHREADS were defined, gthr.h
> would have have directly included gthr-posix.h, but there is a difference
> with respect to the handling of GTHREAD_USE_WEAK.

Ah, I think you posted a very important observation.  libstdc++-v3 has
configuration logic to select a gthr file instead of using the one
selected by the compiler...

In the effort to fix this for all ports: Is there anyone that is
against making libstdc++-v3 always honor the ../gcc/gthr-default.h
selection?

gcc/gthr-* files (of which gthr-default.h points to the correct one
for top-level/gcc-level configuration flags) are all already setup to
correctly handle weak symbols (or, if buggy, we should fix them up
there instead of redoing all the work), etc.

Regards,
Loren