Does hppa-linux-gnu use dwarf2 eh info?

The patch which I am thinking might had caused this is:
2006-09-13  Andreas Krebbel  <krebbel1@de.ibm.com>

        * flow.c (calculate_global_regs_live): Invalidate eh registers
        on eh edges. Renamed invalidated_by_call to invalidated_by_eh_edge.
        (propagate_block): Handle eh registers as if they were set at basic
        block start.
        * except.c (dw2_build_landing_pads): Don't emit clobbers for eh
        registers.
        * global.c (global_conflicts): Make eh registers to conflict with
        pseudos live at basic block begin.
        * basic_block.h (bb_has_eh_pred): New function.

Subject: Re:  [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

> The patch which I am thinking might had caused this is:
> 2006-09-13  Andreas Krebbel  <krebbel1@de.ibm.com>
> 
>         * flow.c (calculate_global_regs_live): Invalidate eh registers
>         on eh edges. Renamed invalidated_by_call to invalidated_by_eh_edge.
>         (propagate_block): Handle eh registers as if they were set at basic
>         block start.
>         * except.c (dw2_build_landing_pads): Don't emit clobbers for eh
>         registers.
>         * global.c (global_conflicts): Make eh registers to conflict with
>         pseudos live at basic block begin.
>         * basic_block.h (bb_has_eh_pred): New function.

While I could see that this might be the cause, it looks like
116942 introduced the failure.  See <http://gcc.gnu.org/ml/gcc-testresults/2006-09/msg00983.html> and <http://gcc.gnu.org/ml/gcc-testresults/2006-09/msg01047.html>.

Dave

Subject: Re:  Timeouts in libstdc++, libjava and libgomp testsuites

> Does hppa-linux-gnu use dwarf2 eh info?

It uses the dwarf2 unwind info.  So, does hpux which doesn't appear
affected.  The same exception_receiver code is generated for both.

Dave

http://gcc.gnu.org/viewcvs?view=rev&revision=116942

This is why I mentioned some of the libstdc++ changes should not be going in.

Huh. Dave, is revision 116942M the same as revision 116942?

Of these, 19_diagnostics/23591_thread-1.c is probably the easiest to debug.

Since this is the linux target, and not the hpux target, the code paths for the locking code should be the same as for x86/linux. 

x86/s390/s390x/powerpc/powerpc64/ia64 all are using these code paths and look fine. What's different about hppa?

-benjamin

Subject: Re:  [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

> Huh. Dave, is revision 116942M the same as revision 116942?

I applied r116954 to 116942. 

> Of these, 19_diagnostics/23591_thread-1.c is probably the easiest to debug.

I'm very busy at the moment, so the earliest I will be able to look at
this is the weekend.

> Since this is the linux target, and not the hpux target, the code paths for the
> locking code should be the same as for x86/linux. 
> 
> x86/s390/s390x/powerpc/powerpc64/ia64 all are using these code paths and look
> fine. What's different about hppa?

It's still using linuxthreads.  Also because of the limitations
of the ldcw semaphore instruction in PA 1.1, the atomic lock type
is 16 bytes and there is a dynamic alignment calculation to
select the aligned 4-byte object to use for the ldcw lock.  As
a result, there are limitations on copying/moving lock objects
that aren't present in other implementations.

NPTL is coming but its not quite ready for prime time.

Dave

> I applied r116954 to 116942. 

Well, then it's still my patch or patches then. Sorry.

> It's still using linuxthreads.  Also because of the limitations
> of the ldcw semaphore instruction in PA 1.1, the atomic lock type
> is 16 bytes and there is a dynamic alignment calculation to
> select the aligned 4-byte object to use for the ldcw lock.  As
> a result, there are limitations on copying/moving lock objects
> that aren't present in other implementations.

Ah. This is interesting, thanks.

One thing you could try, to confirm that this is what's up, is to replace the hppa atomics config with the generic pthreads layer.

Probably the best way to do this is to:

%mv config/cpu/hppa config/cpu/hppa.dis

blow away the build directory, and then rebuild.

During the rebuild, you should see this on the configure line:

...
configure: CPU config directory is cpu/generic
...
checking for thread model used by GCC... posix
checking for atomic builtins... no
...

To confirm, if you go into the freshly built libstdc++/src directory and

ls -al atomicity.cc

You should see it pointing to
config/cpu/generic/atomicity_mutex/atomicity.h

instead of the current 
config/cpu/hppa/atomicity.h

If you try this and run "make check-target-libstdc++-v3" and the testresults are fine, then I can try to put in a hack for you that will bypass the current (presumably flawed) hppa atomics config. Or, we can try to fix it to deal with the limitations that are not present on the other linux cpu's.

best,
-benjamin

Also:

Does hpux use the hppa atomics config, or the generic layer? If it uses the hppa atomics config, why isn't this a problem on hpux?

Subject: Re:  [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

> Does hpux use the hppa atomics config, or the generic layer? If it uses the
> hppa atomics config, why isn't this a problem on hpux?

I believe they use the same atomics.  I think it points to a pthread
issue.

Dave

Subject: Re:  [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

> > Does hpux use the hppa atomics config, or the generic layer? If it uses the
> > hppa atomics config, why isn't this a problem on hpux?
> 
> I believe they use the same atomics.  I think it points to a pthread
> issue.

Further to this point, I used strace to look at pthread6 while it
was executing.  I see a continuous stream of sched_yield calls with
a few nanosleep calls every so often.  Thus, I think the code is
spinning in __pthread_acquire.

This would happen if spinlock/mutex initialization is broken.  Proper
initialization is needed on hppa-linux because locked is 0 and unlocked
is 1.

Dave

Subject: Re:  [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

> One thing you could try, to confirm that this is what's up, is to replace the
> hppa atomics config with the generic pthreads layer.

Doesn't fix problem.

> To confirm, if you go into the freshly built libstdc++/src directory and
> 
> ls -al atomicity.cc
> 
> You should see it pointing to
> config/cpu/generic/atomicity_mutex/atomicity.h
> 
> instead of the current 
> config/cpu/hppa/atomicity.h

Yes, atomicity.cc is pointing to the generic directory.

Dave

Subject: Re:  [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

> Of these, 19_diagnostics/23591_thread-1.c is probably the easiest to debug.

We seem to have an uninitialized mutex:

(gdb) break *0x40b4c6bc
Breakpoint 1 at 0x40b4c6bc: file mutex.c, line 123.
(gdb) cond 1 mutex->__m_lock.__spinlock.lock[0]==0
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /home/dave/gcc-4.2/objdir/hppa-linux/libstdc++-v3/testsuite/23591_thread-1.xg
Error in re-setting breakpoint 1:
No symbol "mutex" in current context.
Error in re-setting breakpoint 1:
No symbol "mutex" in current context.
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 6058)]
[New Thread 32769 (LWP 6059)]
[New Thread 16386 (LWP 6060)]
[Switching to Thread 16386 (LWP 6060)]

Breakpoint 1, 0x40b4c6bc in *__GI___pthread_mutex_lock (mutex=0x41c60000)
    at mutex.c:123
123     mutex.c: No such file or directory.
	in mutex.c
(gdb) p *mutex
$1 = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0,
  __m_lock = {__spinlock = {lock = {0, 0, 0, 0}}, __status = 0}}
(gdb) bt
#0  0x40b4c6bc in *__GI___pthread_mutex_lock (mutex=0x41c60000) at mutex.c:123
#1  0x41ba9a5c in locale (this=0x41c5ece4) at gthr-default.h:549
#2  0x41ba49e4 in Init (this=<value optimized out>) at streambuf:462
#3  0x41bbea94 in __static_initialization_and_destruction_0 (
    __initialize_p=<value optimized out>, __priority=0) at iostream:77
#4  0x41c2d2c0 in __do_global_ctors_aux ()
    from /home/dave/gcc-4.2/objdir/hppa-linux/./libstdc++-v3/src/.libs/libstdc++.so.6
#5  0x41b93984 in _init ()
    from /home/dave/gcc-4.2/objdir/hppa-linux/./libstdc++-v3/src/.libs/libstdc++.so.6
#6  0x402917f8 in _dl_rtld_di_serinfo () from /lib/ld.so.1
#7  0x402919b0 in _dl_rtld_di_serinfo () from /lib/ld.so.1
#8  0x410710a0 in dl_open_worker (a=<value optimized out>) at dl-open.c:504
#9  0x402913a4 in _dl_rtld_di_serinfo () from /lib/ld.so.1
#10 0x410707d4 in *__GI__dl_open (file=0x10aa0 "./testsuite_shared.so",
    mode=-2147483646, caller_dlopen=0x10714, nsid=-2) at dl-open.c:577
#11 0x4037c13c in dlopen_doit (a=0x410b7608) at dlopen.c:59
#12 0x402913a4 in _dl_rtld_di_serinfo () from /lib/ld.so.1
#13 0x4037c620 in _dlerror_run (
    operate=0x41c5d458 <__cxxabiv1::__unexpected_handler+8248>,
    args=0xc025d644) at dlerror.c:162
#14 0x4037c0d0 in __dlopen (file=<value optimized out>, mode=1103486040)
    at dlopen.c:78
#15 0x00010714 in run (arg=<value optimized out>)
    at /home/dave/gcc-4.2/gcc/libstdc++-v3/testsuite/19_diagnostics/23591_thread-1.c:35
#16 0x40b4b28c in pthread_start_thread (arg=0x410b7000) at manager.c:310
#17 0x40b4b628 in pthread_start_thread_event (arg=0x410b7000) at manager.c:334
#18 0x41036134 in thread_start () from /usr/lib/debug/libc.so.6

Dave

Subject: Re:  [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

> Breakpoint 1, 0x40b4c6bc in *__GI___pthread_mutex_lock (mutex=0x41c60000)

(gdb) p locale_mutex
$2 = {_M_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0,
    __m_kind = 0, __m_lock = {__spinlock = {lock = {0, 0, 0, 0}},
    __status = 0}}}
(gdb) p &locale_mutex
$3 = (__gnu_cxx::__mutex *) 0x41c60000

All the "lock" values should be 1 immediately after initialization.

Could this be an ordering problem?

Dave

// try this simpler code.

#include <stdexcept>
#include <ext/concurrence.h>

namespace
{
  __gnu_cxx::__mutex test_mutex;
  unsigned int i;
} // anonymous namespace

void* add(void*)
{
  __gnu_cxx::__scoped_lock sentry(test_mutex);
  {
    ++i; // break here
  }
  return 0;
}

void
check_thread_create(int ret)
{
  if (ret != 0)
    {
      char buf[10];
      sprintf(buf, "%u", ret);

      std::string error("pthread_create failed: ");
      error += buf;
      error += strerror(ret);
      throw std::runtime_error(error);
    }
}

int main()
{
  pthread_t id1;
  pthread_t id2;

  check_thread_create(pthread_create(&id1, NULL, add, 0));
  check_thread_create(pthread_create(&id2, NULL, add, 0));

  pthread_join(id1, NULL);
  pthread_join(id2, NULL);

  return 0;
}

When you get to "break here" this is what your mutex should look like in gdb:

Breakpoint 2, add () at lock_test.cc:14
(gdb) p test_mutex
$4 = {_M_mutex = {__data = {__lock = 1, __count = 0, __owner = 14845, 
      __kind = 0, __nusers = 1, {__spins = 0, __list = {__next = 0x0}}}, 
    __size = "\001\000\000\000\000\000\000\000ý9\000\000\000\000\000\000\001\000\000\000\000\000\000", __align = 1}}

Or, something like this (I see this on x86/linux.)

Actually, if you edit my example a bit and

void* add(void*)
{
  {
    __gnu_cxx::__scoped_lock sentry(test_mutex);
    ++i; // break here
  }
  return 0; // break here
}


On the return statement, you'll see:
(gdb) p test_mutex
$4 = {_M_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, 
      __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, 
    __size = '\0' <repeats 23 times>, __align = 0}}

If this is not happening, then there is something wrong with mutex usage. 

I don't think this is an ordering problem... there are no complicated ordering issues in this code. Something to try might be making test_mutex static, and not in an anonymous namespace. 

I'm not quite sure why hppa is acting so strangely. Can you try a version of hppa-linux that is using NPTL?

best,
benjamin

Subject: Re:  [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

> ------- Comment #16 from bkoz at gcc dot gnu dot org  2006-10-06 09:52 -------
> When you get to "break here" this is what your mutex should look like in gdb:

Well, we don't actually get to "break here".  The program hangs in
xactly the same way as 23591_thread-1:

(gdb) bt
#0  *__GI___pthread_mutex_lock (mutex=0x4010ee00) at mutex.c:99
#1  0x400679e4 in locale (this=0x4010dae4)
    at /home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/include/hppa-linux/bits/gthr-default.h:549
#2  0x40062984 in Init (this=<value optimized out>)
    at /home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/include/streambuf:462
#3  0x4007ca28 in __static_initialization_and_destruction_0 (
    __initialize_p=<value optimized out>, __priority=0)
    at /home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/include/iostream:77
#4  0x400eb140 in __do_global_ctors_aux ()
    from /home/dave/gnu/gcc-4.2/objdir/hppa-linux/./libstdc++-v3/src/.libs/libstdc++.so.6
#5  0x40051924 in _init ()
    from /home/dave/gnu/gcc-4.2/objdir/hppa-linux/./libstdc++-v3/src/.libs/libstdc++.so.6
...
(gdb) p *mutex
$9 = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0,
__m_lock = {__spinlock = {lock = {0, 0, 0, 0}}, __status = 0}}
(gdb) p &locale_mutex
$10 = (__gnu_cxx::__mutex *) 0x4010ee00
(gdb) p mutex
$11 = (pthread_mutex_t *) 0x4010ee00

As can be seen, this occurs running constructors from _init ().  There
are several other calls to __GI___pthread_mutex_lock with properly
initialized mutexes prior to the one shown above which isn't properly
initialized.  A properly initialized mutex looks like:

(gdb) p *mutex
$13 = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0,
  __m_lock = {__spinlock = {lock = {1, 1, 1, 1}}, __status = 0}}

There are two earlier calls to __GI___pthread_mutex_lock from locale.
The first is here:

(gdb) bt
#0  *__GI___pthread_mutex_lock (mutex=0x402e1cb0) at mutex.c:99
#1  0x402ca258 in __pthread_once (once_control=0x4010dff8,
    init_routine=@0x4010bf52: 0x40067568 <std::locale::_S_initialize_once()>)
    at mutex.c:301
#2  0x40067620 in std::locale::_S_initialize ()
    at /home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/include/hppa-linux/bits/gthr-default.h:516
#3  0x4006797c in locale (this=0x402e1cb0)
    at ../../../../gcc/libstdc++-v3/src/locale_init.cc:209
...

(gdb) info symbol 0x402e1cb0
once_masterlock in section .data
(gdb) p mutex
$14 = (pthread_mutex_t *) 0x402e1cb0
(gdb) p *mutex
$15 = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0,
  __m_lock = {__spinlock = {lock = {1, 1, 1, 1}}, __status = 0}}

once_masterlock appears to be statically initialized.

From locale_init.cc:

  locale::locale() throw() : _M_impl(0)
    {
      _S_initialize();
      __gnu_cxx::__scoped_lock sentry(locale_mutex);
      _S_global->_M_add_reference();
      _M_impl = _S_global;
    }

It appears we hang at the "once_masterlock" line.  We never get to
the next line.

Dave

Subject: Re:  [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

> > When you get to "break here" this is what your mutex should look like in gdb:
> 
> Well, we don't actually get to "break here".  The program hangs in
> xactly the same way as 23591_thread-1:

Single stepping from the entry to locale, it doesn't seem like
__mutex() is ever called for locale_mutex.

Dave

Subject: Re:  [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

> It appears we hang at the "once_masterlock" line.  We never get to
> the next line.

Oops, that should have read "_S_initialize();".  Although a break
on the next line is never hit, I think _S_initialize() completes.

Dave

Subject: Re:  [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

> I don't think this is an ordering problem... there are no complicated ordering
> issues in this code. Something to try might be making test_mutex static, and
> not in an anonymous namespace. 

Couldn't the constructor for locale possibly run before the one
for the locale_mutex?

Dave

Subject: Re:  [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

> Couldn't the constructor for locale possibly run before the one
> for the locale_mutex?

The ordering issue is confirmed.  The following change allows the
test program to run successfully and gets us back to where we were
previously with respect to libstdc++ testsuite results.

At "break here", both test_mutex and locale_mutex are properly
initialized.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Index: src/locale_init.cc
===================================================================
--- src/locale_init.cc	(revision 117447)
+++ src/locale_init.cc	(working copy)
@@ -207,7 +207,6 @@
   locale::locale() throw() : _M_impl(0)
   { 
     _S_initialize();
-    __gnu_cxx::__scoped_lock sentry(locale_mutex);
     _S_global->_M_add_reference();
     _M_impl = _S_global;
   }

Created attachment 12399 [details]
patch for mutex init


Can you try this? thanks.

Hey Dave. Thanks for your persistence on this one: I think it's paid off. I can see what you are talking about WRT mutex initialization, and have high hopes for the attached patch. If you can try it, and let me know the results I'd appreciate it.

We can't just remove the mutex in locale::locale. This rationale for this mutex is libstdc++/12658, sadly there is no testcase in the libstdc++ testsuite to check for this. 

Subject: Re:  [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites

> Hey Dave. Thanks for your persistence on this one: I think it's paid off. I can
> see what you are talking about WRT mutex initialization, and have high hopes
> for the attached patch. If you can try it, and let me know the results I'd
> appreciate it.

I rebuilt libstdc++ with the patch and ran through most of the
testsuite without seeing any timeouts.  I'm now doing a complete
bootstrap and check on a couple of systems with todays source.

Thanks,
Dave

Ok. I think I'll put this in.

Subject: Bug 29118

Author: bkoz
Date: Tue Oct 10 10:14:13 2006
New Revision: 117600

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117600
Log:
2006-10-09  Benjamin Kosnik  <bkoz@redhat.com>

	PR libstdc++/29118
	* src/locale_init.cc (__get_locale_mutex): New. 
	(locale::locale): Use it.
	(locale::global): Use it.	


Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/src/locale_init.cc

Fixed.