[uClibc] pthreads BUG?

[Loïc Jeannin]

Hi,

+1 "me too".
(m68knommu)

Btw I'm trying to compile the new uClibc 0.9.24 for m68knommu and it
just barks in pthreads compile:

m68k-elf-gcc -elf2flt -m5307  -Wall -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing   -Wa,--bitwise-or
-I/home/loic/work/uClinux-dist/linux-2.4.x//include   -msoft-float
-fno-builtin -nostdinc -D_LIBC -I../../include -I.
-I/usr/local/lib/gcc-lib/m68k-elf/3.3.2/include -DNDEBUG
-I../../libpthread/linuxthreads/sysdeps/unix/sysv/linux
-I../../libpthread/linuxthreads/sysdeps/pthread
-I../../libpthread/linuxthreads/sysdeps/unix/sysv
-I../../libpthread/linuxthreads/sysdeps/unix/unix
-I../../libpthread/linuxthreads/sysdeps/m68k
-I../../libpthread/linuxthreads/sysdeps -I../../libc/sysdeps/linux/m68k
-c pt-machine.c -o pt-machine.o
/tmp/ccm6GGCz.s: Assembler messages:
/tmp/ccm6GGCz.s:11: Error: operands mismatch -- statement `sne -1(%a6)'
ignored
make[4]: *** [pt-machine.o] Error 1

uClibc/libpthread/linuxthreads/sysdeps/m68k/pt-machine.h
--------------------
#if !defined(__mcoldfire__) && !defined(__mcf5200__) &&
!defined(__m68000)
        "tas %1; sne %0"
#else
         "bset #7,%1; sne %0"
#endif
---------------------

It does the same either with gcc 2.95 toolchain or with gcc 3.3.2
(toolchain by bernardo innocenti). 
The only uclibc that almost work for me is 0.9.19 but pthreads are
_heavily_ bugged : strange behaviour of pthread_mutex_lock, zombie
threads etc ...
Since I've seen some pthreads improvements in the changelogs (0.9.22)
I'm desperately trying to get a working build.

Le mar 16/12/2003 à 02:23, Ken Treis a écrit :
> Miquel Sayeras Oliveras wrote:
> > Somebody has been able to leave thread without this one remains zombie, or
> > creating thread like detached or doing pethread_exit and pthread_join.
> > I've been trying for a while and I have not obtained that thread dies
> > correctly. It's possible bug of threads scheduler??
> 
> Just a "me too" on this (using on m68knommu). After a successful join, 
> the joined thread remains a zombie instead of being properly cleaned up.
> 
> I ended up working around it by using a pthread_cond_wait instead of 
> creating/destroying threads.


Thanks.
-- 
Loïc Jeannin <ljeannin at perax.fr>