sharing mutex between libc stub and libpthread

[manu%netbsd.org@localhost (Emmanuel Dreyfus)]

Followup on the libpthread NOLOAD romoval:

I started writing ATF tests for the removal of libpthread NOLOAD, and
found some "interesting" results. Here are the cases:

Case 1:
- test program is not linked with -lpthread
- main() calls pthread_mutex_init(&mtx, NULL)
- main() calls pthread_mutex_lock(&mtx)
- main() uses dlopen() to load a DSO that is linked with -lpthread
- main() calls pthread_mutex_lunock(&mtx)

Case 2:
- test program is not linked with -lpthread
- main() calls pthread_mutex_init(&mtx, NULL)
- main() calls pthread_mutex_lock(&mtx)
- main() uses dlopen() to load a DSO that is linked with -lpthread
- main() passes mtx to a dso() function in the DSO
- dso() calls pthread_mutex_lunock(&mtx)

In case 1, main() always use the libc stub, even after libpthread has
been loaded in memory. 

In case 2, the mutex is locked using libc stub, and unlocked using
libpthread implementation. This crashes because libc sets the owner
field to -1, and libpthread really expects it to point to a struct
__pthread_st.

Fixing this can be done in two way (and we can go incremental here)
- we may decide that sharing mutex (and condvar and rwlock) between libc
stubs and libpthread is not supported. Is we do this, the minimal libc
stubs should not bother filling mutex fields, it can just set a magic
different than  libpthread one, and return an error if it is given the
libpthread magic.

- supporting the libc to libpthread handover means the implementation
should completely move to libc. libc will have to be aware of struct
__pthread_st, which makes me wonder if there will be much code left in
libpthread.

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu%netbsd.org@localhost