[parisc-linux] [RFC] Where to put arch-dependant locking in malloc/thread-m.h

[Carlos O'Donell <carlos@baldric.uwo.ca>]

libc,

Found the problem with bug-iconv3, it was related to the fact that
hppa's locks can't be initialized to zero (or left unitialized). When
running a non-threaded application and dlopening libpthread the
__libc_maybe_call2's start using the proper strong symbol of those
funcions. At this point malloc on hppa would in certain occassions
fget stuck in a lock that it thought was taken (value of zero).

The following patch fixes the issue, but I'm not content about it's
placement in malloc/thread-m.h. Any comments about where I might put
this in order to make maintenance easier?

Cheers,
Carlos.

diff -u -p -r1.23 thread-m.h
--- glibc/malloc/thread-m.h	1 Jul 2003 08:29:43 -0000	1.23
+++ glibc/malloc/thread-m.h	25 Sep 2003 20:43:55 -0000
@@ -59,6 +59,28 @@ __libc_lock_define (typedef, mutex_t)
 #define mutex_unlock(m)		\
   __libc_maybe_call2 (pthread_mutex_unlock, (m), (*(int *)(m) = 0))
 
+# if(defined __hppa__)
+/* Since our lock structure does not tolerate being initialized to zero, we must
+   modify the standard function calls made by malloc */
+#  undef mutex_init
+#  undef mutex_lock
+#  undef mutex_trylock
+#  undef mutex_unlock
+#  define mutex_init(m)		\
+	__libc_maybe_call (__pthread_mutex_init, (m, NULL), \
+			(((m)->__m_lock.__spinlock = __LT_SPINLOCK_INIT),(*(int *)(m))) )
+#  define mutex_lock(m)		\
+	__libc_maybe_call (__pthread_mutex_lock, (m), \
+			(__load_and_clear(&((m)->__m_lock.__spinlock)), 0))
+#  define mutex_trylock(m)	\
+	__libc_maybe_call (__pthread_mutex_trylock, (m), \
+			(*(int *)(m) ? 1 : (__load_and_clear(&((m)->__m_lock.__spinlock)), 0)))
+#  define mutex_unlock(m)	\
+	__libc_maybe_call (__pthread_mutex_unlock, (m), \
+			(((m)->__m_lock.__spinlock = __LT_SPINLOCK_INIT), (*(int *)(m))) )
+# endif 
+/* if(defined __hppa__) */
+	
 #else
 
 #define mutex_init(m)		\