Re: [rfa/PROBLEMS] document threads/1650, thread internal error

[Michael Chastain <mec.gnu@mindspring.com>]

Argh, I should have read to the end of my mailbox before committing
to gdb HEAD.

> - that it is (to the best of our knowledge) GNU/Linux and LinuxThreads 
> specific

Good question, but your answer is wrong.  Looking at gdb-testers@ for
June and July, I see that hppa2.0w-hp-hpux11.00 and
ia64-unknown-linux-gnu have this problem.  Many other arches can't
compile manythreads.c so we can't tell either way.

  native alphaev67-dec-osf5.1
    couldn't compile the thread tests, so no evidence either way

  native hppa??-??-linux-gnu
    manythreads.exp is okay

  native hppa2.0w-hp-hpux11.00
    manythreads.exp reports these FAILs

  native i686-pc-cygwin
    manythreads.exp is okay

  native ia64-unknown-linux gnu
    gdb HEAD crashes several times timeouts in the threads tests; can't
    even tell if manythreads.exp is running because gdb.sum has plenty
    of "ERROR: internal buffer is full" nearby.

  native powerpc-ibm-aix4.3.3.0
    couldn't compile the thread tests, so no evidence either way

  native powerpc-ibm-aix5.1.0.0
    manythreads.exp reports these FAILS.

  native sparc-sun-solaris 2.8
    couldn't compile this particular test, so no evidence either way

  native x86_64-unknown-linux-gnu
    couldn't compile this particular test, so no evidence either way

> So the closing paragraph should make this clearer.  Something like 
> ``This problem has not been observed on GNU/Linux systems that use NPTL 
> (New Posix Threads Library[?]). People still using linuxthreads are 
> strongly encouraged to migrate to NPTL''.

Shouldn't that be in NEWS?  Maybe I've missed some discussion,
but it's news to me that users linuxthreads are encouraged to
switch.

> We should also mention that on GNU/Linux NPTL based systems a problem 
> with GDB loosing track of threads was fixed.

That sounds good.

Michael C