Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Alexander Kabaev wrote: On Thu, 31 Oct 2002 12:20:14 -0500 (EST) Daniel Eischen [EMAIL PROTECTED] wrote: I wonder how it works for Solaris (you can see both the non-underscore and single-underscore symbols resolve to the same thing)? Perhaps their stubs in libc pull the libgcc trick? Solaris libc uses something called ti_jmp_table to locate pthread symbols. Both _pthread and pthread functions resolve to the same stub which does something like this: 1) fetch a function pointer from the ti_jmp_table 2) jump to it. By default, ti_jump_table entries contain pointers to dummy function like _return_zero if no threading library is loaded. When the threading library is loaded, ti_jump_table is populated with new pointers to functions implemented in threading library library. GDB did not allow me to track down where exactly this happens, I presume .init function in libpthread.so does that. OK, here's a patch that uses a jump table, as well as some other fixes (use single underscore versions of pthread functions internally in libc_r, avoid cancellation points for _pthread_cond_[timed]wait, and other cleanups): http://people.freebsd.org/~deischen/libc-libc_r.diffs Can someone review and test this with GNOME? -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
Daniel Eischen wrote: By default, ti_jump_table entries contain pointers to dummy function like _return_zero if no threading library is loaded. When the threading library is loaded, ti_jump_table is populated with new pointers to functions implemented in threading library library. GDB did not allow me to track down where exactly this happens, I presume .init function in libpthread.so does that. OK, here's a patch that uses a jump table, as well as some other fixes (use single underscore versions of pthread functions internally in libc_r, avoid cancellation points for _pthread_cond_[timed]wait, and other cleanups): http://people.freebsd.org/~deischen/libc-libc_r.diffs Can someone review and test this with GNOME? I don't use gnome, but it seems to work. You are a code-stud. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Wed, Oct 30, 2002 at 06:02:38PM -0800, Juli Mallett wrote: Considering that I built the same applications and ran the same applications fine a while ago, and we've had a binutils upgrade, and things don't break on other systems, I'm inclined to assume there are linker bugs afoot, and all the other speculative stuff seems to be based on misunderstandings or bad information. Huh? Your statement is rather speculative stuff. Other systems (say Linux) are using the same linker we are. Please speculate less. Please grab an older ld and try to prove your speculation. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Wed, 30 Oct 2002, Juli Mallett wrote: * De: Terry Lambert [EMAIL PROTECTED] [ Data: 2002-10-30 ] [ Subjecte: Re: [PATCH: libc]Re: gnome on current ] Maybe the workaround for now is to make the symbols in libXThrStub.so weak? They *are* weak Terry. The problem is that every bloody definition is weak so the linker has no way of picking the one definition which will actually work. The real problem is that the actual working threads library doesn't provide strong symbols to allow it to override all the other stubs. First strong/last weak should win. You are saying last weak is not winning. That's a linker bug. Considering that I built the same applications and ran the same applications fine a while ago, and we've had a binutils upgrade, and things don't break on other systems, I'm inclined to assume there are linker bugs afoot, and all the other speculative stuff seems to be based on misunderstandings or bad information. I'm not misunderstanding things. I single stepped through the call to pthread_setspecific(), watched the linker lookup the symbol and followed it through into the wrong place (i.e. the stub instead of the real implementation). -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Wed, 30 Oct 2002, Daniel Eischen wrote: On Wed, 30 Oct 2002, Alexander Kabaev wrote: On Wed, 30 Oct 2002 15:51:48 -0800 Terry Lambert [EMAIL PROTECTED] wrote: NO. If you have a library that's linked to a library containing string symbols, then no other library gets a chance to replace to symbols with its own strong symbols. The first strong symbol always wins, and the search is defined to be depth-first. You are ignoring the fact, that objects, loaded at the application startup time are getting searched first, followed RTLD_GLOBAL objects, and finally by the loaded object DAG. LD_PRELOAD objects override them all. First strong/last weak should win. You are saying last weak is not winning. That's a linker bug. If last weak will win, the normal case when Xthrstub is loaded _after_ libc_r will break. The only way to really fix this is to export pthread_ symbols as strong in libc_r. Exporting them as weak sounds like is a mistake which should be fixed. I disagree. See Solaris 6, 7, 8 9 for an example. Actually, I don't much care about Solaris. I care that a popular desktop package which we have supported for earlier releases does not work. I don't expect anyone to ever run gnome on Solaris but people certainly run gnome on FreeBSD. If you can find some other way that pthread calls can be directed reliably to libc_r even if some random stub library was loaded first, then fine. Otherwise, it seems that strong definitions for pthread symbols is the only reasonable option (which is why gnome2 works on FreeBSD 4.7 presumably). -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Alexander Kabaev wrote: On Wed, 30 Oct 2002 22:25:12 -0500 (EST) Daniel Eischen [EMAIL PROTECTED] wrote: If last weak will win, the normal case when Xthrstub is loaded _after_ libc_r will break. The only way to really fix this is to export pthread_ symbols as strong in libc_r. Exporting them as weak sounds like is a mistake which should be fixed. I disagree. See Solaris 6, 7, 8 9 for an example. Cool. Then let's be consistent and follow Solaris all the way. Libc on Solaris provides full set of pthread_? functions which in turn call weakly defined _pthread_?? counterparts. libpthread in turn provides strong definitions for _pthread_??. Since in absolute majority of cases libc is the first library searched for symbols, all pthread references will be bound to it and failure described by Doug will not happen. Any library providing strong pthread_ definitions will be able to override ones provided by the system. Our libc is quite different. We define a (weak) set of _pthread_* symbols and libc_r defines a set of strong _pthread_* symbols and a set of weak pthread_* aliases for them. It sounds like libc should define weak _pthread_*, and weak pthread_* aliases for them. Libc_r should define strong _pthread_* symbols and libc's aliases will then resolve to them. That ought to work quite well in this situation and should satisfy everyone. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
hi, there! On Thu, Oct 31, 2002 at 12:39:10AM -0800, David O'Brien wrote: Considering that I built the same applications and ran the same applications fine a while ago, and we've had a binutils upgrade, and things don't break on other systems, I'm inclined to assume there are linker bugs afoot, and all the other speculative stuff seems to be based on misunderstandings or bad information. Huh? Your statement is rather speculative stuff. Other systems (say Linux) are using the same linker we are. Please speculate less. Please grab an older ld and try to prove your speculation. I think the problem is in our dynamic linker or in the way we link dynamic libraries or in the way we compile and link X11 libraries. Linux also has pthreads symbols weakly defined (some of them are defined in glibc, some of them in libpthread) and does not have such problems. /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Alexander Kabaev wrote:
On Wed, 30 Oct 2002 22:25:12 -0500 (EST)
Daniel Eischen [EMAIL PROTECTED] wrote:
If last weak will win, the normal case when Xthrstub is loaded
_after_ libc_r will break. The only way to really fix this is to
export pthread_ symbols as strong in libc_r. Exporting them as weak
sounds like is a mistake which should be fixed.
I disagree. See Solaris 6, 7, 8 9 for an example.
Cool. Then let's be consistent and follow Solaris all the way. Libc on
Solaris provides full set of pthread_? functions which in turn call
weakly defined _pthread_?? counterparts. libpthread in turn provides
strong definitions for _pthread_??.
Since in absolute majority of cases libc is the first library searched
for symbols, all pthread references will be bound to it and failure
described by Doug will not happen.
Any library providing strong pthread_ definitions will be able to
override ones provided by the system.
Something along these lines appears to work nicely and ought to work
either with or without libXThrStub, which is now redundant since libc will
be providing strong symbols that override all the weak symbols in
libXThrStub. We should adjust the XFree86-4-libraries port to avoid
building and using that library.
Index: gen/_pthread_stubs.c
===
RCS file: /home/ncvs/src/lib/libc/gen/_pthread_stubs.c,v
retrieving revision 1.7
diff -u -r1.7 _pthread_stubs.c
--- gen/_pthread_stubs.c19 Sep 2002 01:09:49 - 1.7
+++ gen/_pthread_stubs.c31 Oct 2002 09:31:25 -
@@ -31,6 +31,9 @@
#include pthread.h
#include pthread_np.h
+void *_pthread_getspecific(pthread_key_t key);
+pthread_t _pthread_self(void);
+
/*
* Weak symbols: All libc internal usage of these functions should
* use the weak symbol versions (_pthread_XXX). If libpthread is
@@ -42,6 +45,7 @@
*/
__weak_reference(_pthread_cond_init_stub, _pthread_cond_init);
__weak_reference(_pthread_cond_signal_stub,_pthread_cond_signal);
+__weak_reference(_pthread_cond_broadcast_stub, _pthread_cond_broadcast);
__weak_reference(_pthread_cond_wait_stub, _pthread_cond_wait);
__weak_reference(_pthread_cond_destroy_stub, _pthread_cond_destroy);
__weak_reference(_pthread_getspecific_stub,_pthread_getspecific);
@@ -87,6 +91,12 @@
}
int
+_pthread_cond_broadcast_stub(pthread_cond_t *cond)
+{
+ return (0);
+}
+
+int
_pthread_cond_wait_stub(pthread_cond_t *cond, pthread_mutex_t *mutex)
{
return (0);
@@ -235,4 +245,174 @@
_pthread_sigmask_stub(int how, const sigset_t *set, sigset_t *oset)
{
return (0);
+}
+
+int
+pthread_cond_init(pthread_cond_t *cond,
+const pthread_condattr_t *cond_attr)
+{
+ return (_pthread_cond_init(cond, cond_attr));
+}
+
+int
+pthread_cond_signal(pthread_cond_t *cond)
+{
+ return (_pthread_cond_signal(cond));
+}
+
+int
+pthread_cond_broadcast(pthread_cond_t *cond)
+{
+ return (_pthread_cond_broadcast(cond));
+}
+
+int
+pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t *mutex)
+{
+ return (_pthread_cond_wait(cond, mutex));
+}
+
+int
+pthread_cond_destroy(pthread_cond_t *cond)
+{
+ return (_pthread_cond_destroy(cond));
+}
+
+void *
+pthread_getspecific(pthread_key_t key)
+{
+ return (_pthread_getspecific(key));
+}
+
+int
+pthread_key_create(pthread_key_t *key, void (*destructor) (void *))
+{
+ return (_pthread_key_create(key, destructor));
+}
+
+int
+pthread_key_delete(pthread_key_t key)
+{
+ return (_pthread_key_delete(key));
+}
+
+int
+pthread_main_np()
+{
+ return (_pthread_main_np());
+}
+
+int
+pthread_mutex_destroy(pthread_mutex_t *mattr)
+{
+ return (_pthread_mutex_destroy(mattr));
+}
+
+int
+pthread_mutex_init(pthread_mutex_t *mutex, const pthread_mutexattr_t *mattr)
+{
+ return (_pthread_mutex_init(mutex, mattr));
+}
+
+int
+pthread_mutex_lock(pthread_mutex_t *mutex)
+{
+ return (_pthread_mutex_lock(mutex));
+}
+
+int
+pthread_mutex_trylock(pthread_mutex_t *mutex)
+{
+ return (_pthread_mutex_trylock(mutex));
+}
+
+int
+pthread_mutex_unlock(pthread_mutex_t *mutex)
+{
+ return (_pthread_mutex_unlock(mutex));
+}
+
+int
+pthread_mutexattr_init(pthread_mutexattr_t *mattr)
+{
+ return (_pthread_mutexattr_init(mattr));
+}
+
+int
+pthread_mutexattr_destroy(pthread_mutexattr_t *mattr)
+{
+ return (_pthread_mutexattr_destroy(mattr));
+}
+
+int
+pthread_mutexattr_settype(pthread_mutexattr_t *mattr, int type)
+{
+ return (_pthread_mutexattr_settype(mattr, type));
+}
+
+int
+pthread_once(pthread_once_t *once_control, void (*init_routine) (void))
+{
+ return (_pthread_once(once_control, init_routine));
+}
+
+int
+pthread_rwlock_init(pthread_rwlock_t *rwlock,
+const pthread_rwlockattr_t *attr)
+{
+ return (_pthread_rwlock_init(rwlock, attr));
+}
+
+int
+pthread_rwlock_destroy(pthread_rwlock_t *rwlock)
+{
+ return
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Doug Rabson wrote:
On Thu, 31 Oct 2002, Alexander Kabaev wrote:
On Wed, 30 Oct 2002 22:25:12 -0500 (EST)
Daniel Eischen [EMAIL PROTECTED] wrote:
If last weak will win, the normal case when Xthrstub is loaded
_after_ libc_r will break. The only way to really fix this is to
export pthread_ symbols as strong in libc_r. Exporting them as weak
sounds like is a mistake which should be fixed.
I disagree. See Solaris 6, 7, 8 9 for an example.
Cool. Then let's be consistent and follow Solaris all the way. Libc on
Solaris provides full set of pthread_? functions which in turn call
weakly defined _pthread_?? counterparts. libpthread in turn provides
strong definitions for _pthread_??.
Since in absolute majority of cases libc is the first library searched
for symbols, all pthread references will be bound to it and failure
described by Doug will not happen.
Any library providing strong pthread_ definitions will be able to
override ones provided by the system.
Something along these lines appears to work nicely and ought to work
either with or without libXThrStub, which is now redundant since libc will
be providing strong symbols that override all the weak symbols in
libXThrStub. We should adjust the XFree86-4-libraries port to avoid
building and using that library.
This version works better - it fixes some typos in the rwlock stubs.
Index: gen/_pthread_stubs.c
===
RCS file: /home/ncvs/src/lib/libc/gen/_pthread_stubs.c,v
retrieving revision 1.7
diff -u -r1.7 _pthread_stubs.c
--- gen/_pthread_stubs.c19 Sep 2002 01:09:49 - 1.7
+++ gen/_pthread_stubs.c31 Oct 2002 10:10:42 -
@@ -31,6 +31,9 @@
#include pthread.h
#include pthread_np.h
+void *_pthread_getspecific(pthread_key_t key);
+pthread_t _pthread_self(void);
+
/*
* Weak symbols: All libc internal usage of these functions should
* use the weak symbol versions (_pthread_XXX). If libpthread is
@@ -42,6 +45,7 @@
*/
__weak_reference(_pthread_cond_init_stub, _pthread_cond_init);
__weak_reference(_pthread_cond_signal_stub,_pthread_cond_signal);
+__weak_reference(_pthread_cond_broadcast_stub, _pthread_cond_broadcast);
__weak_reference(_pthread_cond_wait_stub, _pthread_cond_wait);
__weak_reference(_pthread_cond_destroy_stub, _pthread_cond_destroy);
__weak_reference(_pthread_getspecific_stub,_pthread_getspecific);
@@ -59,9 +63,10 @@
__weak_reference(_pthread_once_stub, _pthread_once);
__weak_reference(_pthread_self_stub, _pthread_self);
__weak_reference(_pthread_rwlock_init_stub,_pthread_rwlock_init);
+__weak_reference(_pthread_rwlock_destroy_stub, _pthread_rwlock_destroy);
__weak_reference(_pthread_rwlock_rdlock_stub, _pthread_rwlock_rdlock);
__weak_reference(_pthread_rwlock_tryrdlock_stub, _pthread_rwlock_tryrdlock);
-__weak_reference(_pthread_rwlock_trywrlock_stub, _pthread_rwlock_trywrloc);
+__weak_reference(_pthread_rwlock_trywrlock_stub, _pthread_rwlock_trywrlock);
__weak_reference(_pthread_rwlock_unlock_stub, _pthread_rwlock_unlock);
__weak_reference(_pthread_rwlock_wrlock_stub, _pthread_rwlock_wrlock);
__weak_reference(_pthread_setspecific_stub,_pthread_setspecific);
@@ -87,6 +92,12 @@
}
int
+_pthread_cond_broadcast_stub(pthread_cond_t *cond)
+{
+ return (0);
+}
+
+int
_pthread_cond_wait_stub(pthread_cond_t *cond, pthread_mutex_t *mutex)
{
return (0);
@@ -235,4 +246,174 @@
_pthread_sigmask_stub(int how, const sigset_t *set, sigset_t *oset)
{
return (0);
+}
+
+int
+pthread_cond_init(pthread_cond_t *cond,
+const pthread_condattr_t *cond_attr)
+{
+ return (_pthread_cond_init(cond, cond_attr));
+}
+
+int
+pthread_cond_signal(pthread_cond_t *cond)
+{
+ return (_pthread_cond_signal(cond));
+}
+
+int
+pthread_cond_broadcast(pthread_cond_t *cond)
+{
+ return (_pthread_cond_broadcast(cond));
+}
+
+int
+pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t *mutex)
+{
+ return (_pthread_cond_wait(cond, mutex));
+}
+
+int
+pthread_cond_destroy(pthread_cond_t *cond)
+{
+ return (_pthread_cond_destroy(cond));
+}
+
+void *
+pthread_getspecific(pthread_key_t key)
+{
+ return (_pthread_getspecific(key));
+}
+
+int
+pthread_key_create(pthread_key_t *key, void (*destructor) (void *))
+{
+ return (_pthread_key_create(key, destructor));
+}
+
+int
+pthread_key_delete(pthread_key_t key)
+{
+ return (_pthread_key_delete(key));
+}
+
+int
+pthread_main_np()
+{
+ return (_pthread_main_np());
+}
+
+int
+pthread_mutex_destroy(pthread_mutex_t *mattr)
+{
+ return (_pthread_mutex_destroy(mattr));
+}
+
+int
+pthread_mutex_init(pthread_mutex_t *mutex, const pthread_mutexattr_t *mattr)
+{
+ return (_pthread_mutex_init(mutex, mattr));
+}
+
+int
+pthread_mutex_lock(pthread_mutex_t *mutex)
+{
+ return (_pthread_mutex_lock(mutex));
+}
+
+int
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Max Khon wrote: hi, there! On Thu, Oct 31, 2002 at 12:39:10AM -0800, David O'Brien wrote: Considering that I built the same applications and ran the same applications fine a while ago, and we've had a binutils upgrade, and things don't break on other systems, I'm inclined to assume there are linker bugs afoot, and all the other speculative stuff seems to be based on misunderstandings or bad information. Huh? Your statement is rather speculative stuff. Other systems (say Linux) are using the same linker we are. Please speculate less. Please grab an older ld and try to prove your speculation. I think the problem is in our dynamic linker or in the way we link dynamic libraries or in the way we compile and link X11 libraries. Linux also has pthreads symbols weakly defined (some of them are defined in glibc, some of them in libpthread) and does not have such problems. I think you are mistaken. On my RedHat 8.0 system, there are weak pthread_* symbols in libc.so and strong ones in libpthread.so. Linux doesn't use libXThrStub.so, presumably because libc.so's pthread_* symbols are suitable stubs. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
* De: David O'Brien [EMAIL PROTECTED] [ Data: 2002-10-31 ] [ Subjecte: Re: [PATCH: libc]Re: gnome on current ] On Wed, Oct 30, 2002 at 06:02:38PM -0800, Juli Mallett wrote: Considering that I built the same applications and ran the same applications fine a while ago, and we've had a binutils upgrade, and things don't break on other systems, I'm inclined to assume there are linker bugs afoot, and all the other speculative stuff seems to be based on misunderstandings or bad information. Huh? Your statement is rather speculative stuff. Other systems (say Linux) are using the same linker we are. Please speculate less. Please grab an older ld and try to prove your speculation. It's deductive. Other systems are using similar library setups, in terms of weak vs. strong systems, and some of those are very well supported by GNOME by a commercial vendor, or will be if not now for GNOME2. I'm running GNOME2 right now that was built about two weeks before the last binutils upgrade, which had about 900 lines of ChangeLog entries associated with it. The symbol strength in libc and libc_r has not changed similarly in that time. I was just throwing my speculation based on my experiences with what is working, trying to keep in mind what has changed in the mean time, and what is involved with what's going on. Which Linux distributions have the symbol strength as we do, have libXThrStub in their link lines, -and- are using the same binutils as us? I'm not saying that has to be it, I'm saying given what I'm writing this reply on/inside, I'm saying I doubt dfr's insistance on breaking non libc_r.so thread libraries being the only thing is seeming more and more wrong, as I ldd every binary I'm currently running. juli. -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Alexander Kabaev wrote: On Wed, 30 Oct 2002 22:25:12 -0500 (EST) Daniel Eischen [EMAIL PROTECTED] wrote: If last weak will win, the normal case when Xthrstub is loaded _after_ libc_r will break. The only way to really fix this is to export pthread_ symbols as strong in libc_r. Exporting them as weak sounds like is a mistake which should be fixed. I disagree. See Solaris 6, 7, 8 9 for an example. Cool. Then let's be consistent and follow Solaris all the way. Libc on Solaris provides full set of pthread_? functions which in turn call weakly defined _pthread_?? counterparts. libpthread in turn provides strong definitions for _pthread_??. No, please see earlier messages in this thread. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Doug Rabson wrote:
On Wed, 30 Oct 2002, Daniel Eischen wrote:
On Wed, 30 Oct 2002, Alexander Kabaev wrote:
On Wed, 30 Oct 2002 15:51:48 -0800
Terry Lambert [EMAIL PROTECTED] wrote:
NO.
If you have a library that's linked to a library containing string
symbols, then no other library gets a chance to replace to symbols
with its own strong symbols. The first strong symbol always wins,
and the search is defined to be depth-first.
You are ignoring the fact, that objects, loaded at the application startup
time are getting searched first, followed RTLD_GLOBAL objects, and finally by
the loaded object DAG. LD_PRELOAD objects override them all.
First strong/last weak should win. You are saying last weak is not
winning. That's a linker bug.
If last weak will win, the normal case when Xthrstub is loaded _after_ libc_r
will break. The only way to really fix this is to export pthread_ symbols as
strong in libc_r. Exporting them as weak sounds like is a mistake which
should be fixed.
I disagree. See Solaris 6, 7, 8 9 for an example.
Actually, I don't much care about Solaris. I care that a popular desktop
package which we have supported for earlier releases does not work. I
don't expect anyone to ever run gnome on Solaris but people certainly run
gnome on FreeBSD.
Umm, isn't GNOME going to be Solaris' window toolkit. Sun said this
months ago, upsetting some of the KDE folks.
Have you looked at how libgcc uses pthread routines? It doesn't
have a problem.
Basically, it wraps all the pthread functions which could be done
something like this:
--
Dan Eischen
%%% libxthr.h %%%
#ifndef _LIBXTHR_H_
#define _LIBXTHR_H_
#include pthread.h
int xthr_isthreaded(void);
int xthr_mutex_lock(pthread_mutex_t *);
int xthr_mutex_unlock(pthread_mutex_t *);
#endif
%%%
%%% libxthr.c %%%
#include unistd.h
#include stdlib.h
#include libxthr.h
#pragma weak pthread_create;
#pragma weak pthread_mutex_lock;
#pragma weak pthread_mutex_unlock;
static void *pthread_create_addr = (void *)pthread_create;
int
xthr_isthreaded(void)
{
return (pthread_create_addr != NULL);
}
int
xthr_mutex_lock(pthread_mutex_t *mutex);
{
if (xthr_isthreaded())
return (pthread_mutex_lock(mutex));
else
return (0);
}
int
xthr_mutex_unlock(pthread_mutex_t *mutex);
{
if (xthr_isthreaded())
return (pthread_mutex_unlock(mutex));
else
return (0);
}
%%%
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Doug Rabson wrote: On Thu, 31 Oct 2002, Alexander Kabaev wrote: On Wed, 30 Oct 2002 22:25:12 -0500 (EST) Daniel Eischen [EMAIL PROTECTED] wrote: If last weak will win, the normal case when Xthrstub is loaded _after_ libc_r will break. The only way to really fix this is to export pthread_ symbols as strong in libc_r. Exporting them as weak sounds like is a mistake which should be fixed. I disagree. See Solaris 6, 7, 8 9 for an example. Cool. Then let's be consistent and follow Solaris all the way. Libc on Solaris provides full set of pthread_? functions which in turn call weakly defined _pthread_?? counterparts. libpthread in turn provides strong definitions for _pthread_??. Since in absolute majority of cases libc is the first library searched for symbols, all pthread references will be bound to it and failure described by Doug will not happen. Any library providing strong pthread_ definitions will be able to override ones provided by the system. Something along these lines appears to work nicely and ought to work either with or without libXThrStub, which is now redundant since libc will be providing strong symbols that override all the weak symbols in libXThrStub. We should adjust the XFree86-4-libraries port to avoid building and using that library. Please no, you've got strong pthread_* symbols in libc. I'd rather see them as strong in libpthread (but don't really want that either). You can also play the libgcc game inside of libc for those applications or libraries that are too lazy to do it for themselves. Have the libc pthread stubs key on a weak reference to pthread_create and call the pthread_* if they are present. libXThrStub should be able to do that though. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002 09:08:12 -0500 (EST) Daniel Eischen [EMAIL PROTECTED] wrote: Cool. Then let's be consistent and follow Solaris all the way. Libc on Solaris provides full set of pthread_? functions which in turn call weakly defined _pthread_?? counterparts. libpthread in turn provides strong definitions for _pthread_??. No, please see earlier messages in this thread. Dan, could you please be consistent? You cited Solaris as an example against making all the symbols in libc_r strong. I gave you an answer that the only way why this works on Solaris is because libc itself provides weak pthread_ definitions. pthread_ functions in libc simply call their _pthread counterparts, which are also weekly defined in libc. libpthread defines _pthread_ symbols as strong and consequently its symbols override one provided by libc. Saying 'NO' to strong symbols in libc_r because Solaris does not do that and then saying 'NO' again to description on how Solaris really does things - that's where I lost you. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
* De: Juli Mallett [EMAIL PROTECTED] [ Data: 2002-10-31 ] [ Subjecte: Re: [PATCH: libc]Re: gnome on current ] * De: David O'Brien [EMAIL PROTECTED] [ Data: 2002-10-31 ] [ Subjecte: Re: [PATCH: libc]Re: gnome on current ] On Wed, Oct 30, 2002 at 06:02:38PM -0800, Juli Mallett wrote: Considering that I built the same applications and ran the same applications fine a while ago, and we've had a binutils upgrade, and things don't break on other systems, I'm inclined to assume there are linker bugs afoot, and all the other speculative stuff seems to be based on misunderstandings or bad information. Huh? Your statement is rather speculative stuff. Other systems (say Linux) are using the same linker we are. Please speculate less. Please grab an older ld and try to prove your speculation. It's deductive. And wrong, too! Finally took a simple testcase, an old libexec/elf/ld, etc., and it still goes boom. On to checking the runtime linker, I suppose. -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Daniel Eischen wrote: On Thu, 31 Oct 2002, Doug Rabson wrote: On Thu, 31 Oct 2002, Alexander Kabaev wrote: On Wed, 30 Oct 2002 22:25:12 -0500 (EST) Daniel Eischen [EMAIL PROTECTED] wrote: If last weak will win, the normal case when Xthrstub is loaded _after_ libc_r will break. The only way to really fix this is to export pthread_ symbols as strong in libc_r. Exporting them as weak sounds like is a mistake which should be fixed. I disagree. See Solaris 6, 7, 8 9 for an example. Cool. Then let's be consistent and follow Solaris all the way. Libc on Solaris provides full set of pthread_? functions which in turn call weakly defined _pthread_?? counterparts. libpthread in turn provides strong definitions for _pthread_??. Since in absolute majority of cases libc is the first library searched for symbols, all pthread references will be bound to it and failure described by Doug will not happen. Any library providing strong pthread_ definitions will be able to override ones provided by the system. Something along these lines appears to work nicely and ought to work either with or without libXThrStub, which is now redundant since libc will be providing strong symbols that override all the weak symbols in libXThrStub. We should adjust the XFree86-4-libraries port to avoid building and using that library. Please no, you've got strong pthread_* symbols in libc. I'd rather see them as strong in libpthread (but don't really want that either). You can also play the libgcc game inside of libc for those applications or libraries that are too lazy to do it for themselves. Have the libc pthread stubs key on a weak reference to pthread_create and call the pthread_* if they are present. libXThrStub should be able to do that though. It almost doesn't matter which of the solutions we use as long as we do something. What we currently have is clearly wrong but I'll list it along with the others. Solutions so far proposed are: 0. (Current behaviour). Define _pthread_* weakly in libc. A pthreads implementation defines strong _pthread_* symbols and weak pthread_* aliases for them. Anyone else which defines pthread_* symbols (either weak or strong) can take over and will normally end up breaking libc. 1. Define pthread_* strongly in libc. Make these strong symbols call weak _pthread_* counterparts also defined in libc. A pthreads implementation defines strong _pthread_* symbols allowing it to 'take over' from libc. 2. Define weak _pthread_* symbols in libc and probably weak pthread_* symbols either in libc or somewhere else (libXThrStub?). A pthreads implementation defines strong _pthread_* and strong pthread_*. This is the linux solution (without the _pthread_* indirection). 3. Like (0) but rewrite X11's thread code so that every call looks something like: if (pthreads) return pthread_foo(args); else return 0; This isn't likely to be easy to get back into the XFree86 codebase and makes us gratuitously different from the rest of the world, most of which neither need nor have libXThrStub. 4. Something else, e.g. more fine-grained control over symbol resolution beyond strong/weak. Probably not worth the effort. Right now, I can't tell what Solaris does. Alexander suggested that it was (1) but you disagree. It would be interesting to see the output of 'nm | grep pthread' for both libc.so and libpthread.so. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Alexander Kabaev wrote: On Thu, 31 Oct 2002 09:08:12 -0500 (EST) Daniel Eischen [EMAIL PROTECTED] wrote: Cool. Then let's be consistent and follow Solaris all the way. Libc on Solaris provides full set of pthread_? functions which in turn call weakly defined _pthread_?? counterparts. libpthread in turn provides strong definitions for _pthread_??. No, please see earlier messages in this thread. Dan, could you please be consistent? You cited Solaris as an example against making all the symbols in libc_r strong. I gave you an answer that the only way why this works on Solaris is because libc itself provides weak pthread_ definitions. pthread_ functions in libc simply call their _pthread counterparts, which are also weekly defined in libc. libpthread defines _pthread_ symbols as strong and consequently its symbols override one provided by libc. No, you stated that Solaris libpthread defines pthread_ symbols strong. It doesn't. Perhaps you really meant _pthread_ symbols, which is what you say above. For the record, neither libc nor libthread or libpthread in Solaris provide strong pthread_* symbols. They (Solaris) do provide strong _pthread_* symbols in libpthread, as we do in libc_r. bash-2.05$ uname -rvs SunOS 5.8 Generic_108528-12 bash-2.05$ nm /usr/lib/libpthread.so.1 | grep pthread_mutex_lock 3c80 T _pthread_mutex_lock 3c80 W pthread_mutex_lock bash-2.05$ nm /usr/lib/libc.so.1 | grep pthread_mutex_lock 00096c38 W _pthread_mutex_lock 00096c38 W pthread_mutex_lock We also have an additional requirement in libc. Our uses of _pthread_* in libc must correspond to the [single underscore] _pthread_* in libc_r (and libpthread eventually). All references to [non underscore] pthread_* routines must correspond to the [two underscore] __pthread_* routines in libc_r. This is so our threads libraries can tell the difference between application and implementation locks. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002 05:45:43 -0800 Juli Mallett [EMAIL PROTECTED] wrote: * De: David O'Brien [EMAIL PROTECTED] [ Data: 2002-10-31 ] [ Subjecte: Re: [PATCH: libc]Re: gnome on current ] On Wed, Oct 30, 2002 at 06:02:38PM -0800, Juli Mallett wrote: Considering that I built the same applications and ran the same applications fine a while ago, and we've had a binutils upgrade, and things don't break on other systems, I'm inclined to assume there are linker bugs afoot, and all the other speculative stuff seems to be based on misunderstandings or bad information. Huh? Your statement is rather speculative stuff. Other systems (say Linux) are using the same linker we are. Please speculate less. Please grab an older ld and try to prove your speculation. It's deductive. Other systems are using similar library setups, in terms of weak vs. strong systems, Wrong. Solaris and Linux differ from FreeBSD each in its own way. Linuxprovides strong pthread definitions in libpthread Solaris provides weak pthread and _pthread definitions in Libc with libpthread providing strong _pthread and weak pthread We are the weird one it seems. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Alexander Kabaev wrote: On Thu, 31 Oct 2002 05:45:43 -0800 Juli Mallett [EMAIL PROTECTED] wrote: * De: David O'Brien [EMAIL PROTECTED] [ Data: 2002-10-31 ] [ Subjecte: Re: [PATCH: libc]Re: gnome on current ] On Wed, Oct 30, 2002 at 06:02:38PM -0800, Juli Mallett wrote: Considering that I built the same applications and ran the same applications fine a while ago, and we've had a binutils upgrade, and things don't break on other systems, I'm inclined to assume there are linker bugs afoot, and all the other speculative stuff seems to be based on misunderstandings or bad information. Huh? Your statement is rather speculative stuff. Other systems (say Linux) are using the same linker we are. Please speculate less. Please grab an older ld and try to prove your speculation. It's deductive. Other systems are using similar library setups, in terms of weak vs. strong systems, Wrong. Solaris and Linux differ from FreeBSD each in its own way. Linuxprovides strong pthread definitions in libpthread Solaris provides weak pthread and _pthread definitions in Libc with libpthread providing strong _pthread and weak pthread We are the weird one it seems. The only thing that we don't do that Solaris does, is provide weak pthread_ definitions in libc. I'm not opposed to that; I'm opposed to providing strong pthread_ definitions either in libc or libc_r. I added all the weak definitions so that we would look exactly like Solaris libpthread. This was the model I chose when I did this almost 2 years ago. We've been using it that long without any problems until now. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Daniel Eischen wrote: On Thu, 31 Oct 2002, Alexander Kabaev wrote: On Thu, 31 Oct 2002 09:08:12 -0500 (EST) Daniel Eischen [EMAIL PROTECTED] wrote: Cool. Then let's be consistent and follow Solaris all the way. Libc on Solaris provides full set of pthread_? functions which in turn call weakly defined _pthread_?? counterparts. libpthread in turn provides strong definitions for _pthread_??. No, please see earlier messages in this thread. Dan, could you please be consistent? You cited Solaris as an example against making all the symbols in libc_r strong. I gave you an answer that the only way why this works on Solaris is because libc itself provides weak pthread_ definitions. pthread_ functions in libc simply call their _pthread counterparts, which are also weekly defined in libc. libpthread defines _pthread_ symbols as strong and consequently its symbols override one provided by libc. No, you stated that Solaris libpthread defines pthread_ symbols strong. It doesn't. Perhaps you really meant _pthread_ symbols, which is what you say above. For the record, neither libc nor libthread or libpthread in Solaris provide strong pthread_* symbols. They (Solaris) do provide strong _pthread_* symbols in libpthread, as we do in libc_r. bash-2.05$ uname -rvs SunOS 5.8 Generic_108528-12 bash-2.05$ nm /usr/lib/libpthread.so.1 | grep pthread_mutex_lock 3c80 T _pthread_mutex_lock 3c80 W pthread_mutex_lock bash-2.05$ nm /usr/lib/libc.so.1 | grep pthread_mutex_lock 00096c38 W _pthread_mutex_lock 00096c38 W pthread_mutex_lock Now I'm really confused. I can't see how this can work properly. Imagine the following scenario: An application 'base' is linked against libc and is not threaded. This application loads a plugin 'Xplug.so' via dlopen(). Xplug doesn't use threads but it does link against libX11.so which calls pthread_mutex_* etc. to ensure thread-safety. Since libX11 doesn't want to force threading unless its needed, it just uses libc's weak versions. Finally, 'Threadplug.so' is loaded which does use threads. This object is linked with libpthread.so which is now in the list of libs, crucially *after* libc.so. After all this loading and runtime linking, the question is how does libX11 manage to call the right pthread routines? It isn't linked directly to libpthread.so and the first weak definition of pthread_foo is from libc.so. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
I'll respond to two messages in one. No, you stated that Solaris libpthread defines pthread_ symbols strong. It doesn't. Perhaps you really meant _pthread_ symbols, which is what you say above. No, I meant a simple fact that Solaris provides weak definition for both _pthread and pthread symbols. I assumed you have seen the pthread definition in libc since you brought that example up. I apologize if 'weak' got omitted from my message and got you confused. In another message: The only thing that we don't do that Solaris does, is provide weak pthread_ definitions in libc. I'm not opposed to that; I'm opposed to providing strong pthread_ definitions either in libc or libc_r. Then we are in complete agreement. Adding weak aliases for pthread symbols is what I mean under following Solaris all the way. We've been using it that long without any problems until now. But loading libc_r linked libraries into non-threaded processes din't work ever since libc_r got split from libc. This is a weird case which does not happen a lot in the wild anyway. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Doug Rabson wrote: On Thu, 31 Oct 2002, Daniel Eischen wrote: You can also play the libgcc game inside of libc for those applications or libraries that are too lazy to do it for themselves. Have the libc pthread stubs key on a weak reference to pthread_create and call the pthread_* if they are present. libXThrStub should be able to do that though. It almost doesn't matter which of the solutions we use as long as we do something. What we currently have is clearly wrong but I'll list it along with the others. Solutions so far proposed are: 0. (Current behaviour). Define _pthread_* weakly in libc. A pthreads implementation defines strong _pthread_* symbols and weak pthread_* aliases for them. Anyone else which defines pthread_* symbols (either weak or strong) can take over and will normally end up breaking libc. We only use _pthread_* in libc, so it doesn't break libc unless they provide strong symbols for _pthread_*. Our implementation relies on the use of single underscore versions in libc so we can tell the difference between the implementation locks and application locks. The weak references from pthread_* in libc_r are to the double underscore versions (mostly, the locking functions) so that applications actually resolve to __pthread_mutex_lock and libc uses will resolve to _pthread_mutex_lock. 1. Define pthread_* strongly in libc. Make these strong symbols call weak _pthread_* counterparts also defined in libc. A pthreads implementation defines strong _pthread_* symbols allowing it to 'take over' from libc. 2. Define weak _pthread_* symbols in libc and probably weak pthread_* symbols either in libc or somewhere else (libXThrStub?). A pthreads implementation defines strong _pthread_* and strong pthread_*. This is the linux solution (without the _pthread_* indirection). 3. Like (0) but rewrite X11's thread code so that every call looks something like: if (pthreads) return pthread_foo(args); else return 0; This isn't likely to be easy to get back into the XFree86 codebase and makes us gratuitously different from the rest of the world, most of which neither need nor have libXThrStub. 4. Something else, e.g. more fine-grained control over symbol resolution beyond strong/weak. Probably not worth the effort. Right now, I can't tell what Solaris does. Alexander suggested that it was (1) but you disagree. It would be interesting to see the output of 'nm | grep pthread' for both libc.so and libpthread.so. I've already done that and posted it. Here it is again. bash-2.05$ uname -rvs SunOS 5.8 Generic_108528-12 bash-2.05$ nm /usr/lib/libc.so.1 | grep pthread_mutex_ 00054a08 t _libc_pthread_mutex_init 00096bc0 W _pthread_mutex_destroy 00096be8 W _pthread_mutex_getprioceiling 00096c10 W _pthread_mutex_init 00096c38 W _pthread_mutex_lock 00096c60 W _pthread_mutex_setprioceiling 00096c88 W _pthread_mutex_trylock 00096cb0 W _pthread_mutex_unlock 00096bc0 W pthread_mutex_destroy 00096be8 W pthread_mutex_getprioceiling 00096c10 W pthread_mutex_init 00096c38 W pthread_mutex_lock 00096c60 W pthread_mutex_setprioceiling 00096c88 W pthread_mutex_trylock 00096cb0 W pthread_mutex_unlock bash-2.05$ nm /usr/lib/libpthread.so.1 | grep pthread_mutex_ 3d28 T _pthread_mutex_attr_gettype 3d20 T _pthread_mutex_attr_settype 3c38 T _pthread_mutex_consistent_np 3c78 T _pthread_mutex_destroy 3ca0 T _pthread_mutex_getprioceiling 3c70 T _pthread_mutex_init 3c80 T _pthread_mutex_lock 3c98 T _pthread_mutex_setprioceiling 3c90 T _pthread_mutex_trylock 3c88 T _pthread_mutex_unlock 3d28 W pthread_mutex_attr_gettype 3d20 W pthread_mutex_attr_settype 3c38 W pthread_mutex_consistent_np 3c78 W pthread_mutex_destroy 3ca0 W pthread_mutex_getprioceiling 3c70 W pthread_mutex_init 3c80 W pthread_mutex_lock 3c98 W pthread_mutex_setprioceiling 3c90 W pthread_mutex_trylock 3c88 W pthread_mutex_unlock -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Daniel Eischen wrote:
On Thu, 31 Oct 2002, Doug Rabson wrote:
On Thu, 31 Oct 2002, Daniel Eischen wrote:
You can also play the libgcc game inside of libc for those applications
or libraries that are too lazy to do it for themselves. Have the
libc pthread stubs key on a weak reference to pthread_create and
call the pthread_* if they are present. libXThrStub should be
able to do that though.
It almost doesn't matter which of the solutions we use as long as we do
something. What we currently have is clearly wrong but I'll list it along
with the others. Solutions so far proposed are:
0. (Current behaviour). Define _pthread_* weakly in libc. A pthreads
implementation defines strong _pthread_* symbols and weak pthread_*
aliases for them. Anyone else which defines pthread_* symbols (either weak
or strong) can take over and will normally end up breaking libc.
We only use _pthread_* in libc, so it doesn't break libc unless
they provide strong symbols for _pthread_*. Our implementation
relies on the use of single underscore versions in libc so we
can tell the difference between the implementation locks and
application locks. The weak references from pthread_* in libc_r
are to the double underscore versions (mostly, the locking
functions) so that applications actually resolve to __pthread_mutex_lock
and libc uses will resolve to _pthread_mutex_lock.
Actually its pretty easy to break libc. Someone calls flockfile() which in
turn calls _pthread_mutex_lock(). This ends up in libc_r which notices
that the mutex is uninitialised and calls init_static(). That calls
pthread_mutex_init() and dies shortly afterwards (note the non-_pthread
call from init_static()).
Right now, I can't tell what Solaris does. Alexander suggested that it was
(1) but you disagree. It would be interesting to see the output of 'nm |
grep pthread' for both libc.so and libpthread.so.
I've already done that and posted it. Here it is again.
...
Ok then. Next attempt. This one defines weak pthread_foo stubs which call
_pthread_foo. It also defines weak _pthread_foo stubs which are noops. All
symbols weak. Everyone happy. Actually, I haven't tested this since my
test system is at home. For kicks, I also staticised the stubs.
Index: gen/_pthread_stubs.c
===
RCS file: /home/ncvs/src/lib/libc/gen/_pthread_stubs.c,v
retrieving revision 1.7
diff -u -r1.7 _pthread_stubs.c
--- gen/_pthread_stubs.c19 Sep 2002 01:09:49 - 1.7
+++ gen/_pthread_stubs.c31 Oct 2002 15:39:50 -
@@ -31,6 +31,9 @@
#include pthread.h
#include pthread_np.h
+void *_pthread_getspecific(pthread_key_t key);
+pthread_t _pthread_self(void);
+
/*
* Weak symbols: All libc internal usage of these functions should
* use the weak symbol versions (_pthread_XXX). If libpthread is
@@ -42,6 +45,7 @@
*/
__weak_reference(_pthread_cond_init_stub, _pthread_cond_init);
__weak_reference(_pthread_cond_signal_stub,_pthread_cond_signal);
+__weak_reference(_pthread_cond_broadcast_stub, _pthread_cond_broadcast);
__weak_reference(_pthread_cond_wait_stub, _pthread_cond_wait);
__weak_reference(_pthread_cond_destroy_stub, _pthread_cond_destroy);
__weak_reference(_pthread_getspecific_stub,_pthread_getspecific);
@@ -59,9 +63,10 @@
__weak_reference(_pthread_once_stub, _pthread_once);
__weak_reference(_pthread_self_stub, _pthread_self);
__weak_reference(_pthread_rwlock_init_stub,_pthread_rwlock_init);
+__weak_reference(_pthread_rwlock_destroy_stub, _pthread_rwlock_destroy);
__weak_reference(_pthread_rwlock_rdlock_stub, _pthread_rwlock_rdlock);
__weak_reference(_pthread_rwlock_tryrdlock_stub, _pthread_rwlock_tryrdlock);
-__weak_reference(_pthread_rwlock_trywrlock_stub, _pthread_rwlock_trywrloc);
+__weak_reference(_pthread_rwlock_trywrlock_stub, _pthread_rwlock_trywrlock);
__weak_reference(_pthread_rwlock_unlock_stub, _pthread_rwlock_unlock);
__weak_reference(_pthread_rwlock_wrlock_stub, _pthread_rwlock_wrlock);
__weak_reference(_pthread_setspecific_stub,_pthread_setspecific);
@@ -73,166 +78,371 @@
static struct pthread main_thread;
-int
+static int
_pthread_cond_init_stub(pthread_cond_t *cond,
const pthread_condattr_t *cond_attr)
{
return (0);
}
-int
+static int
_pthread_cond_signal_stub(pthread_cond_t *cond)
{
return (0);
}
-int
+static int
+_pthread_cond_broadcast_stub(pthread_cond_t *cond)
+{
+ return (0);
+}
+
+static int
_pthread_cond_wait_stub(pthread_cond_t *cond, pthread_mutex_t *mutex)
{
return (0);
}
-int
+static int
_pthread_cond_destroy_stub(pthread_cond_t *cond)
{
return (0);
}
-void *
+static void *
_pthread_getspecific_stub(pthread_key_t key)
{
return (NULL);
}
-int
+static int
_pthread_key_create_stub(pthread_key_t *key, void (*destructor) (void *))
{
return (0);
}
-int
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Doug Rabson wrote: On Thu, 31 Oct 2002, Daniel Eischen wrote: On Thu, 31 Oct 2002, Doug Rabson wrote: On Thu, 31 Oct 2002, Daniel Eischen wrote: You can also play the libgcc game inside of libc for those applications or libraries that are too lazy to do it for themselves. Have the libc pthread stubs key on a weak reference to pthread_create and call the pthread_* if they are present. libXThrStub should be able to do that though. It almost doesn't matter which of the solutions we use as long as we do something. What we currently have is clearly wrong but I'll list it along with the others. Solutions so far proposed are: 0. (Current behaviour). Define _pthread_* weakly in libc. A pthreads implementation defines strong _pthread_* symbols and weak pthread_* aliases for them. Anyone else which defines pthread_* symbols (either weak or strong) can take over and will normally end up breaking libc. We only use _pthread_* in libc, so it doesn't break libc unless they provide strong symbols for _pthread_*. Our implementation relies on the use of single underscore versions in libc so we can tell the difference between the implementation locks and application locks. The weak references from pthread_* in libc_r are to the double underscore versions (mostly, the locking functions) so that applications actually resolve to __pthread_mutex_lock and libc uses will resolve to _pthread_mutex_lock. Actually its pretty easy to break libc. Someone calls flockfile() which in turn calls _pthread_mutex_lock(). This ends up in libc_r which notices that the mutex is uninitialised and calls init_static(). That calls pthread_mutex_init() and dies shortly afterwards (note the non-_pthread call from init_static()). I don't see how that can be. _pthread_mutex_lock() in libc_r calls init_static_private(), not init_static(). Right now, I can't tell what Solaris does. Alexander suggested that it was (1) but you disagree. It would be interesting to see the output of 'nm | grep pthread' for both libc.so and libpthread.so. I've already done that and posted it. Here it is again. ... Ok then. Next attempt. This one defines weak pthread_foo stubs which call _pthread_foo. It also defines weak _pthread_foo stubs which are noops. All symbols weak. Everyone happy. Actually, I haven't tested this since my test system is at home. For kicks, I also staticised the stubs. This is better, although it has two stubs for each routine. Adding a weak definition from pthread_foo() to _pthread_foo() (note the lack of _stub) doesn't do the same thing? -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Daniel Eischen wrote: On Thu, 31 Oct 2002, Doug Rabson wrote: On Thu, 31 Oct 2002, Daniel Eischen wrote: On Thu, 31 Oct 2002, Doug Rabson wrote: On Thu, 31 Oct 2002, Daniel Eischen wrote: You can also play the libgcc game inside of libc for those applications or libraries that are too lazy to do it for themselves. Have the libc pthread stubs key on a weak reference to pthread_create and call the pthread_* if they are present. libXThrStub should be able to do that though. It almost doesn't matter which of the solutions we use as long as we do something. What we currently have is clearly wrong but I'll list it along with the others. Solutions so far proposed are: 0. (Current behaviour). Define _pthread_* weakly in libc. A pthreads implementation defines strong _pthread_* symbols and weak pthread_* aliases for them. Anyone else which defines pthread_* symbols (either weak or strong) can take over and will normally end up breaking libc. We only use _pthread_* in libc, so it doesn't break libc unless they provide strong symbols for _pthread_*. Our implementation relies on the use of single underscore versions in libc so we can tell the difference between the implementation locks and application locks. The weak references from pthread_* in libc_r are to the double underscore versions (mostly, the locking functions) so that applications actually resolve to __pthread_mutex_lock and libc uses will resolve to _pthread_mutex_lock. Actually its pretty easy to break libc. Someone calls flockfile() which in turn calls _pthread_mutex_lock(). This ends up in libc_r which notices that the mutex is uninitialised and calls init_static(). That calls pthread_mutex_init() and dies shortly afterwards (note the non-_pthread call from init_static()). I don't see how that can be. _pthread_mutex_lock() in libc_r calls init_static_private(), not init_static(). That was it (I single stepped through this in the debugger a couple of days ago). Unfortunately init_static_private() also calls pthread_mutex_init() without the leading underscore. Right now, I can't tell what Solaris does. Alexander suggested that it was (1) but you disagree. It would be interesting to see the output of 'nm | grep pthread' for both libc.so and libpthread.so. I've already done that and posted it. Here it is again. ... Ok then. Next attempt. This one defines weak pthread_foo stubs which call _pthread_foo. It also defines weak _pthread_foo stubs which are noops. All symbols weak. Everyone happy. Actually, I haven't tested this since my test system is at home. For kicks, I also staticised the stubs. This is better, although it has two stubs for each routine. Adding a weak definition from pthread_foo() to _pthread_foo() (note the lack of _stub) doesn't do the same thing? I already tried that one this morning. The assignment happens at compile time unfortunately. What I wanted was for pthread_foo to be resolved in rtld to the best available _pthread_foo. Unforunately the resolution happens at link time and by the time we get to rtld, we just have a pthread_foo which happens to have the same value as _pthread_foo. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Doug Rabson wrote: On Thu, 31 Oct 2002, Daniel Eischen wrote: On Thu, 31 Oct 2002, Doug Rabson wrote: We only use _pthread_* in libc, so it doesn't break libc unless they provide strong symbols for _pthread_*. Our implementation relies on the use of single underscore versions in libc so we can tell the difference between the implementation locks and application locks. The weak references from pthread_* in libc_r are to the double underscore versions (mostly, the locking functions) so that applications actually resolve to __pthread_mutex_lock and libc uses will resolve to _pthread_mutex_lock. Actually its pretty easy to break libc. Someone calls flockfile() which in turn calls _pthread_mutex_lock(). This ends up in libc_r which notices that the mutex is uninitialised and calls init_static(). That calls pthread_mutex_init() and dies shortly afterwards (note the non-_pthread call from init_static()). I don't see how that can be. _pthread_mutex_lock() in libc_r calls init_static_private(), not init_static(). That was it (I single stepped through this in the debugger a couple of days ago). Unfortunately init_static_private() also calls pthread_mutex_init() without the leading underscore. And because it calls the non-underscore version, this breaks something? I guess both init_static_private and init_static should both call _pthread_mutex_init. Right now, I can't tell what Solaris does. Alexander suggested that it was (1) but you disagree. It would be interesting to see the output of 'nm | grep pthread' for both libc.so and libpthread.so. I've already done that and posted it. Here it is again. ... Ok then. Next attempt. This one defines weak pthread_foo stubs which call _pthread_foo. It also defines weak _pthread_foo stubs which are noops. All symbols weak. Everyone happy. Actually, I haven't tested this since my test system is at home. For kicks, I also staticised the stubs. This is better, although it has two stubs for each routine. Adding a weak definition from pthread_foo() to _pthread_foo() (note the lack of _stub) doesn't do the same thing? I already tried that one this morning. The assignment happens at compile time unfortunately. What I wanted was for pthread_foo to be resolved in rtld to the best available _pthread_foo. Unforunately the resolution happens at link time and by the time we get to rtld, we just have a pthread_foo which happens to have the same value as _pthread_foo. I wonder how it works for Solaris (you can see both the non-underscore and single-underscore symbols resolve to the same thing)? Perhaps their stubs in libc pull the libgcc trick? -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Daniel Eischen wrote: On Thu, 31 Oct 2002, Doug Rabson wrote: On Thu, 31 Oct 2002, Daniel Eischen wrote: I don't see how that can be. _pthread_mutex_lock() in libc_r calls init_static_private(), not init_static(). That was it (I single stepped through this in the debugger a couple of days ago). Unfortunately init_static_private() also calls pthread_mutex_init() without the leading underscore. And because it calls the non-underscore version, this breaks something? I guess both init_static_private and init_static should both call _pthread_mutex_init. Yes. In my case it ended up in a noop stub defined by libXThrStub.so. Right afterwards libc_r bombed because the mutex it tried to initialise wasn't initialised. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002 12:20:14 -0500 (EST) Daniel Eischen [EMAIL PROTECTED] wrote: I wonder how it works for Solaris (you can see both the non-underscore and single-underscore symbols resolve to the same thing)? Perhaps their stubs in libc pull the libgcc trick? Solaris libc uses something called ti_jmp_table to locate pthread symbols. Both _pthread and pthread functions resolve to the same stub which does something like this: 1) fetch a function pointer from the ti_jmp_table 2) jump to it. By default, ti_jump_table entries contain pointers to dummy function like _return_zero if no threading library is loaded. When the threading library is loaded, ti_jump_table is populated with new pointers to functions implemented in threading library library. GDB did not allow me to track down where exactly this happens, I presume .init function in libpthread.so does that. Just FYI. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Alexander Kabaev wrote: On Thu, 31 Oct 2002 12:20:14 -0500 (EST) Daniel Eischen [EMAIL PROTECTED] wrote: I wonder how it works for Solaris (you can see both the non-underscore and single-underscore symbols resolve to the same thing)? Perhaps their stubs in libc pull the libgcc trick? Solaris libc uses something called ti_jmp_table to locate pthread symbols. Both _pthread and pthread functions resolve to the same stub which does something like this: 1) fetch a function pointer from the ti_jmp_table 2) jump to it. By default, ti_jump_table entries contain pointers to dummy function like _return_zero if no threading library is loaded. When the threading library is loaded, ti_jump_table is populated with new pointers to functions implemented in threading library library. GDB did not allow me to track down where exactly this happens, I presume .init function in libpthread.so does that. That sounds easy enough to do. Anyone think this is a bad idea? -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Daniel Eischen wrote:
This is better, although it has two stubs for each routine. Adding
a weak definition from pthread_foo() to _pthread_foo() (note the
lack of _stub) doesn't do the same thing?
Ok, this version works and seems to be a reasonably tidy solution, at
least until/if the jump-table version a-la solaris is available. I
tweaked it slightly to move all the __weak_reference() calls together. Can
I commit this?
Index: gen/_pthread_stubs.c
===
RCS file: /home/ncvs/src/lib/libc/gen/_pthread_stubs.c,v
retrieving revision 1.7
diff -u -r1.7 _pthread_stubs.c
--- gen/_pthread_stubs.c19 Sep 2002 01:09:49 - 1.7
+++ gen/_pthread_stubs.c31 Oct 2002 19:30:24 -
@@ -31,6 +31,9 @@
#include pthread.h
#include pthread_np.h
+void *_pthread_getspecific(pthread_key_t key);
+pthread_t _pthread_self(void);
+
/*
* Weak symbols: All libc internal usage of these functions should
* use the weak symbol versions (_pthread_XXX). If libpthread is
@@ -42,6 +45,7 @@
*/
__weak_reference(_pthread_cond_init_stub, _pthread_cond_init);
__weak_reference(_pthread_cond_signal_stub,_pthread_cond_signal);
+__weak_reference(_pthread_cond_broadcast_stub, _pthread_cond_broadcast);
__weak_reference(_pthread_cond_wait_stub, _pthread_cond_wait);
__weak_reference(_pthread_cond_destroy_stub, _pthread_cond_destroy);
__weak_reference(_pthread_getspecific_stub,_pthread_getspecific);
@@ -59,180 +63,386 @@
__weak_reference(_pthread_once_stub, _pthread_once);
__weak_reference(_pthread_self_stub, _pthread_self);
__weak_reference(_pthread_rwlock_init_stub,_pthread_rwlock_init);
+__weak_reference(_pthread_rwlock_destroy_stub, _pthread_rwlock_destroy);
__weak_reference(_pthread_rwlock_rdlock_stub, _pthread_rwlock_rdlock);
__weak_reference(_pthread_rwlock_tryrdlock_stub, _pthread_rwlock_tryrdlock);
-__weak_reference(_pthread_rwlock_trywrlock_stub, _pthread_rwlock_trywrloc);
+__weak_reference(_pthread_rwlock_trywrlock_stub, _pthread_rwlock_trywrlock);
__weak_reference(_pthread_rwlock_unlock_stub, _pthread_rwlock_unlock);
__weak_reference(_pthread_rwlock_wrlock_stub, _pthread_rwlock_wrlock);
__weak_reference(_pthread_setspecific_stub,_pthread_setspecific);
__weak_reference(_pthread_sigmask_stub,_pthread_sigmask);
+__weak_reference(pthread_cond_init_stub, pthread_cond_init);
+__weak_reference(pthread_cond_signal_stub, pthread_cond_signal);
+__weak_reference(pthread_cond_broadcast_stub, pthread_cond_broadcast);
+__weak_reference(pthread_cond_wait_stub, pthread_cond_wait);
+__weak_reference(pthread_cond_destroy_stub,pthread_cond_destroy);
+__weak_reference(pthread_getspecific_stub, pthread_getspecific);
+__weak_reference(pthread_key_create_stub, pthread_key_create);
+__weak_reference(pthread_key_delete_stub, pthread_key_delete);
+__weak_reference(pthread_main_np_stub, pthread_main_np);
+__weak_reference(pthread_mutex_destroy_stub, pthread_mutex_destroy);
+__weak_reference(pthread_mutex_init_stub, pthread_mutex_init);
+__weak_reference(pthread_mutex_lock_stub, pthread_mutex_lock);
+__weak_reference(pthread_mutex_trylock_stub, pthread_mutex_trylock);
+__weak_reference(pthread_mutex_unlock_stub,pthread_mutex_unlock);
+__weak_reference(pthread_mutexattr_init_stub, pthread_mutexattr_init);
+__weak_reference(pthread_mutexattr_destroy_stub, pthread_mutexattr_destroy);
+__weak_reference(pthread_mutexattr_settype_stub, pthread_mutexattr_settype);
+__weak_reference(pthread_once_stub,pthread_once);
+__weak_reference(pthread_self_stub,pthread_self);
+__weak_reference(pthread_rwlock_init_stub, pthread_rwlock_init);
+__weak_reference(pthread_rwlock_destroy_stub, pthread_rwlock_destroy);
+__weak_reference(pthread_rwlock_rdlock_stub, pthread_rwlock_rdlock);
+__weak_reference(pthread_rwlock_tryrdlock_stub, pthread_rwlock_tryrdlock);
+__weak_reference(pthread_rwlock_trywrlock_stub, pthread_rwlock_trywrlock);
+__weak_reference(pthread_rwlock_unlock_stub, pthread_rwlock_unlock);
+__weak_reference(pthread_rwlock_wrlock_stub, pthread_rwlock_wrlock);
+__weak_reference(pthread_setspecific_stub, pthread_setspecific);
+__weak_reference(pthread_sigmask_stub, pthread_sigmask);
+
/* Define a null pthread structure just to satisfy _pthread_self. */
struct pthread {
};
static struct pthread main_thread;
-int
+static int
_pthread_cond_init_stub(pthread_cond_t *cond,
const pthread_condattr_t *cond_attr)
{
return (0);
}
-int
+static int
_pthread_cond_signal_stub(pthread_cond_t *cond)
{
return (0);
}
-int
+static int
+_pthread_cond_broadcast_stub(pthread_cond_t *cond)
+{
+ return (0);
+}
+
+static int
_pthread_cond_wait_stub(pthread_cond_t *cond, pthread_mutex_t *mutex)
{
return (0);
}
-int
+static int
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Doug Rabson wrote: On Thu, 31 Oct 2002, Daniel Eischen wrote: This is better, although it has two stubs for each routine. Adding a weak definition from pthread_foo() to _pthread_foo() (note the lack of _stub) doesn't do the same thing? Ok, this version works and seems to be a reasonably tidy solution, at least until/if the jump-table version a-la solaris is available. I tweaked it slightly to move all the __weak_reference() calls together. Can I commit this? Yes, it looks OK. I started a slightly different version that automatically added both references with one macro. Something like: #define WEAK_REF(sym, alias)__weak_reference(sym, alias) #define DUAL_WEAK_STUB(sym) \ WEAK_REF(__CONCAT(sym, _stub), __CONCAT(_, sym)); \ WEAK_REF(__CONCAT(sym, _stub), sym) DUAL_WEAK_STUB(pthread_mutex_lock); ... or something like that. Go ahead and commit yours if you don't care to fiddle any more with it. I won't be able to get to the jump table thing for a few days. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
Doug Rabson wrote: On Thu, 31 Oct 2002, Daniel Eischen wrote: It almost doesn't matter which of the solutions we use as long as we do something. What we currently have is clearly wrong but I'll list it along with the others. Solutions so far proposed are: [ ... ] 2. Define weak _pthread_* symbols in libc and probably weak pthread_* symbols either in libc or somewhere else (libXThrStub?). A pthreads implementation defines strong _pthread_* and strong pthread_*. This is the linux solution (without the _pthread_* indirection). Actually, Alexander was suggesting: 2. Define weak _pthread_* symbols in libc and weak pthread_* symbols in libc. A pthreads implementation defines strong _pthread_* and **does not define** pthread_*. This is the Solaris solution. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
Alexander Kabaev wrote: Wrong. Solaris and Linux differ from FreeBSD each in its own way. Linuxprovides strong pthread definitions in libpthread Solaris provides weak pthread and _pthread definitions in Libc with libpthread providing strong _pthread and weak pthread We are the weird one it seems. Exactly. My only question is the necessity of the weak pthread in libpthread (our libc_r). It seems to not be needed, but is harmless (IMO). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
Daniel Eischen wrote: We also have an additional requirement in libc. Our uses of _pthread_* in libc must correspond to the [single underscore] _pthread_* in libc_r (and libpthread eventually). All references to [non underscore] pthread_* routines must correspond to the [two underscore] __pthread_* routines in libc_r. This is so our threads libraries can tell the difference between application and implementation locks. I understand the distinction being drawn there, but the X11 lib XThrStub.so is really an attempt to erase it. It doesn't make a lot of sense to make such a distinction, if you're just going to have to do a lot of work to cover it up again. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
Doug Rabson wrote: Now I'm really confused. I can't see how this can work properly. Imagine the following scenario: An application 'base' is linked against libc and is not threaded. This application loads a plugin 'Xplug.so' via dlopen(). Xplug doesn't use threads but it does link against libX11.so which calls pthread_mutex_* etc. to ensure thread-safety. Since libX11 doesn't want to force threading unless its needed, it just uses libc's weak versions. Finally, 'Threadplug.so' is loaded which does use threads. This object is linked with libpthread.so which is now in the list of libs, crucially *after* libc.so. After all this loading and runtime linking, the question is how does libX11 manage to call the right pthread routines? It isn't linked directly to libpthread.so and the first weak definition of pthread_foo is from libc.so. It's ugly, but... The answer is that it's expected to do one of two things: o The framework supports loading of threaded modules, and therefore the framework itself is limked against libc_r, which means that libX11 is linked against libc_r, and get the pthreads complete mutex/cond/etc. code. o The framework doesn't support loading of threaded modules, in which case a threaded module is either expected to: o Serialize calls to X11 functions through a single worker thread, OR o dlopen libX11 after dlopen of libc_r, and then use threads through its own stub references, OR o Be linked against libc_r and libX11 (in that order) so that it gets a different instance of the library in question; the reentrancy issue only applies to the threads against a given library instance -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
Alexander Kabaev wrote: By default, ti_jump_table entries contain pointers to dummy function like _return_zero if no threading library is loaded. When the threading library is loaded, ti_jump_table is populated with new pointers to functions implemented in threading library library. GDB did not allow me to track down where exactly this happens, I presume .init function in libpthread.so does that. Using .init for this isn't strictly possible. Only one .init is invoked by the crt0, so if you replace it, you displace the code that would normally call the static constructors. You can't use a static constructor, because you don't get the environment block as a parameter to each constructor in the linker set traversed by the default .init. I ran into this same problem when creating a libdlopen; the other issue in the area is that even if you fix the parameter to be void * instead of void (with a coincidental value of the value of the address of the environment block), you don't necessarily get the correct order. The only way you can really deal with this is to either have a secondary linker set, or to have a priority parameter, and convert the thing to structure pointers instead of function pointers, and then bubble sort on priority (kind of like what I did in the SYSINIT() code). The same thing goes for a library that creates its own worker thread, and then serializes requests in a queue to wrap a non-reentrant library with a thread-safe wrapper (e.g. the Netscape LDAP client library). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Wed, 30 Oct 2002, Terry Lambert wrote: Doug Rabson wrote: All you have to do is create a situation where a shared object that links to libc_r is loaded after libX11 and the thing breaks into little pieces. So let's dike out libXThrStub.so, and be done with it. I think the only stub which it defines that libc.so doesn't also define is pthread_cond_broadcast. I'm waiting to see if that lack causes any noticeable problems. That's bizarre... it's defined in libc_r, so there's no reason for the omission in libc. I only added stubs that I thought the implementation of libc used (or would use). Please find attached a patch that corrects this. Patch looks correct. PS: It looks like the semaphore code use pthread_cond_signal; maybe it should be using the pthread_cond_broadcast, instead? This seeems to be broken, if we are talking a large vs. small count on the semaphore... Semaphores only increment/decrement the semaphore by 1. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
Daniel Eischen wrote: That's bizarre... it's defined in libc_r, so there's no reason for the omission in libc. I only added stubs that I thought the implementation of libc used (or would use). Makes sense. Actually, it looks like most of this could be done with macros, including the function definitions, so that we are just dealing with lists; I didn't go that far with it. Please find attached a patch that corrects this. Patch looks correct. Please commit? 8-). PS: It looks like the semaphore code use pthread_cond_signal; maybe it should be using the pthread_cond_broadcast, instead? This seeems to be broken, if we are talking a large vs. small count on the semaphore... Semaphores only increment/decrement the semaphore by 1. In the code in question, it looks like a thundering herd race is a correct thing to do to avoid starvation; maybe I'm reading it wrong. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Wed, 30 Oct 2002, Terry Lambert wrote: Daniel Eischen wrote: That's bizarre... it's defined in libc_r, so there's no reason for the omission in libc. I only added stubs that I thought the implementation of libc used (or would use). Makes sense. Actually, it looks like most of this could be done with macros, including the function definitions, so that we are just dealing with lists; I didn't go that far with it. Please find attached a patch that corrects this. Patch looks correct. Please commit? 8-). Well I made a libc with this patch and rebuilt XFree86-4-libraries without libXThrStub but I ran into problems compiling the clients. The clients *require* someone in the link to supply the pthread_* symbols and libc.so only had _pthread_* symbols. I added some more weak references to libc.so but that just gets us back to square one. The problem is that the sawfish configuration tools are written using some extensible lisp/scheme thing called rep. The main rep binary links against libc.so so that occurs early in the list. Later on stacks of libraries are loaded dynamically, some of which depend on libc_r.so. Unfortunately libc_r.so is far too late in the list to get a lookin and it dies in exactly the same way as before, for the same reason (calling a non-functional stub version of pthread_setspecific(). -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
Doug Rabson wrote: On Wed, 30 Oct 2002, Terry Lambert wrote: Daniel Eischen wrote: Patch looks correct. Please commit? 8-). Well I made a libc with this patch and rebuilt XFree86-4-libraries without libXThrStub but I ran into problems compiling the clients. The clients *require* someone in the link to supply the pthread_* symbols and libc.so only had _pthread_* symbols. I added some more weak references to libc.so but that just gets us back to square one. The problem is that the sawfish configuration tools are written using some extensible lisp/scheme thing called rep. The main rep binary links against libc.so so that occurs early in the list. Later on stacks of libraries are loaded dynamically, some of which depend on libc_r.so. Unfortunately libc_r.so is far too late in the list to get a lookin and it dies in exactly the same way as before, for the same reason (calling a non-functional stub version of pthread_setspecific(). You need to link the library against libc_r.so instead of libXThrStub.so. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Wed, 30 Oct 2002, Doug Rabson wrote: On Wed, 30 Oct 2002, Terry Lambert wrote: Daniel Eischen wrote: That's bizarre... it's defined in libc_r, so there's no reason for the omission in libc. I only added stubs that I thought the implementation of libc used (or would use). Makes sense. Actually, it looks like most of this could be done with macros, including the function definitions, so that we are just dealing with lists; I didn't go that far with it. Please find attached a patch that corrects this. Patch looks correct. Please commit? 8-). Well I made a libc with this patch and rebuilt XFree86-4-libraries without libXThrStub but I ran into problems compiling the clients. The clients *require* someone in the link to supply the pthread_* symbols and libc.so only had _pthread_* symbols. I added some more weak references to libc.so but that just gets us back to square one. I think Terry might be right in suggesting using a macro to automate all the link and stub generation... The problem is that the sawfish configuration tools are written using some extensible lisp/scheme thing called rep. The main rep binary links against libc.so so that occurs early in the list. Later on stacks of libraries are loaded dynamically, some of which depend on libc_r.so. Unfortunately libc_r.so is far too late in the list to get a lookin and it dies in exactly the same way as before, for the same reason (calling a non-functional stub version of pthread_setspecific(). Well, it must have the same problem with Solaris then. Somehow, you've got to force it to link libc_r before libc... -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Wed, 30 Oct 2002, Daniel Eischen wrote: On Wed, 30 Oct 2002, Doug Rabson wrote: On Wed, 30 Oct 2002, Terry Lambert wrote: Daniel Eischen wrote: That's bizarre... it's defined in libc_r, so there's no reason for the omission in libc. I only added stubs that I thought the implementation of libc used (or would use). Makes sense. Actually, it looks like most of this could be done with macros, including the function definitions, so that we are just dealing with lists; I didn't go that far with it. Please find attached a patch that corrects this. Patch looks correct. Please commit? 8-). Well I made a libc with this patch and rebuilt XFree86-4-libraries without libXThrStub but I ran into problems compiling the clients. The clients *require* someone in the link to supply the pthread_* symbols and libc.so only had _pthread_* symbols. I added some more weak references to libc.so but that just gets us back to square one. I think Terry might be right in suggesting using a macro to automate all the link and stub generation... The problem is that the sawfish configuration tools are written using some extensible lisp/scheme thing called rep. The main rep binary links against libc.so so that occurs early in the list. Later on stacks of libraries are loaded dynamically, some of which depend on libc_r.so. Unfortunately libc_r.so is far too late in the list to get a lookin and it dies in exactly the same way as before, for the same reason (calling a non-functional stub version of pthread_setspecific(). Well, it must have the same problem with Solaris then. Somehow, you've got to force it to link libc_r before libc... The only way I can see to do that is to link libX11, libXt and friends against libc_r. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Wed, 30 Oct 2002, Terry Lambert wrote: Doug Rabson wrote: On Wed, 30 Oct 2002, Terry Lambert wrote: Daniel Eischen wrote: Patch looks correct. Please commit? 8-). Well I made a libc with this patch and rebuilt XFree86-4-libraries without libXThrStub but I ran into problems compiling the clients. The clients *require* someone in the link to supply the pthread_* symbols and libc.so only had _pthread_* symbols. I added some more weak references to libc.so but that just gets us back to square one. The problem is that the sawfish configuration tools are written using some extensible lisp/scheme thing called rep. The main rep binary links against libc.so so that occurs early in the list. Later on stacks of libraries are loaded dynamically, some of which depend on libc_r.so. Unfortunately libc_r.so is far too late in the list to get a lookin and it dies in exactly the same way as before, for the same reason (calling a non-functional stub version of pthread_setspecific(). You need to link the library against libc_r.so instead of libXThrStub.so. Probably not. Doing that breaks the existing 'feature' of being able to use X11 in entirely non-threaded programs. I'm not sure whether that is acceptable. It also stops programs from being able to select between several thread implementations, of which -current has two. I think the only sensible solution to this problem is for libraries which provide an actual pthreads implementation (rather than a set of stubs) to define strong symbols. Wierd debugging wrappers can still be achieved via some dlopen/dlsym hackery. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Wed, 30 Oct 2002, Doug Rabson wrote: On Wed, 30 Oct 2002, Terry Lambert wrote: Doug Rabson wrote: On Wed, 30 Oct 2002, Terry Lambert wrote: Daniel Eischen wrote: Patch looks correct. Please commit? 8-). Well I made a libc with this patch and rebuilt XFree86-4-libraries without libXThrStub but I ran into problems compiling the clients. The clients *require* someone in the link to supply the pthread_* symbols and libc.so only had _pthread_* symbols. I added some more weak references to libc.so but that just gets us back to square one. The problem is that the sawfish configuration tools are written using some extensible lisp/scheme thing called rep. The main rep binary links against libc.so so that occurs early in the list. Later on stacks of libraries are loaded dynamically, some of which depend on libc_r.so. Unfortunately libc_r.so is far too late in the list to get a lookin and it dies in exactly the same way as before, for the same reason (calling a non-functional stub version of pthread_setspecific(). You need to link the library against libc_r.so instead of libXThrStub.so. Probably not. Doing that breaks the existing 'feature' of being able to use X11 in entirely non-threaded programs. I'm not sure whether that is acceptable. It also stops programs from being able to select between several thread implementations, of which -current has two. I think the only sensible solution to this problem is for libraries which provide an actual pthreads implementation (rather than a set of stubs) to define strong symbols. Wierd debugging wrappers can still be achieved via some dlopen/dlsym hackery. For what its worth, doing this (defining strong pthread_* symbols in libc_r) makes everything work fine, with or without libXThrStub. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
Doug Rabson wrote: On Wed, 30 Oct 2002, Daniel Eischen wrote: Well, it must have the same problem with Solaris then. Somehow, you've got to force it to link libc_r before libc... The only way I can see to do that is to link libX11, libXt and friends against libc_r. What this comes down to is that we've grown a distruct of libc_r, and we think that the things that are pulling the threads in have no business running threads, or forcing your program to link threaded when it's not using threads. The problem is that they *are* using threads, if they are using a library that uses threads. In the Western U.S., we'd say Cowboy Up, and eat the overhead!. If there are going to be libraries which, by their nature, suck threads in, then we are just going to have to live with it. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
Doug Rabson wrote: You need to link the library against libc_r.so instead of libXThrStub.so. Probably not. Doing that breaks the existing 'feature' of being able to use X11 in entirely non-threaded programs. I'm not sure whether that is acceptable. It also stops programs from being able to select between several thread implementations, of which -current has two. I think the only sensible solution to this problem is for libraries which provide an actual pthreads implementation (rather than a set of stubs) to define strong symbols. Wierd debugging wrappers can still be achieved via some dlopen/dlsym hackery. OK... I guess I don't understand the problem. If you are not compiling threaded programs for use with X, and X itself is not threaded, then why the heck was the threads stuff there in the first place? If X itself uses threads, then you need to use threads: there's no option in the matter. If libX11.so does not reference, the threads symbols, who cares? If libX11.so *does* reference the threads symbols, then they need to be there. You can't have a library that's sort of threaded and sort of not threaded: pick one. If you want a seperate libdlopen, then I can help you: I did some of the code necessary to implement this already, but stopped because there needs to be a change to the constructor arguments to pass the address of the arg list down to the constructors, so you can use a constructor section in a linker set to do the init that's necessary to get at the symbols. I didn't want to have to fight the rest of you to get that mod into libc and the crt0 code. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
Doug Rabson wrote: I think the only sensible solution to this problem is for libraries which provide an actual pthreads implementation (rather than a set of stubs) to define strong symbols. Wierd debugging wrappers can still be achieved via some dlopen/dlsym hackery. For what its worth, doing this (defining strong pthread_* symbols in libc_r) makes everything work fine, with or without libXThrStub. No, this would be bad. There's some justification for not doing this, in allowing programs linked againts libraries linked against threaded libraries to link against alternate threads libraries. If the symbols are stong, then this is not possible. Maybe the workaround for now is to make the symbols in libXThrStub.so weak? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Wed, 30 Oct 2002, Terry Lambert wrote: Doug Rabson wrote: You need to link the library against libc_r.so instead of libXThrStub.so. Probably not. Doing that breaks the existing 'feature' of being able to use X11 in entirely non-threaded programs. I'm not sure whether that is acceptable. It also stops programs from being able to select between several thread implementations, of which -current has two. I think the only sensible solution to this problem is for libraries which provide an actual pthreads implementation (rather than a set of stubs) to define strong symbols. Wierd debugging wrappers can still be achieved via some dlopen/dlsym hackery. OK... I guess I don't understand the problem. If you are not compiling threaded programs for use with X, and X itself is not threaded, then why the heck was the threads stuff there in the first place? If X itself uses threads, then you need to use threads: there's no option in the matter. If libX11.so does not reference, the threads symbols, who cares? If libX11.so *does* reference the threads symbols, then they need to be there. You can't have a library that's sort of threaded and sort of not threaded: pick one. Yes you can - libX11 is *thread safe* but doesn't create threads. When a real pthreads implementation is present, libX11 uses its implementation of mutex, cond etc. to ensure its own safety. If the application doesn't link to a real pthreads implementation, it uses no-op stubs instead. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Wed, 30 Oct 2002, Terry Lambert wrote: Doug Rabson wrote: I think the only sensible solution to this problem is for libraries which provide an actual pthreads implementation (rather than a set of stubs) to define strong symbols. Wierd debugging wrappers can still be achieved via some dlopen/dlsym hackery. For what its worth, doing this (defining strong pthread_* symbols in libc_r) makes everything work fine, with or without libXThrStub. No, this would be bad. There's some justification for not doing this, in allowing programs linked againts libraries linked against threaded libraries to link against alternate threads libraries. If the symbols are stong, then this is not possible. Wrong. Either link the app to libc_r or to libpthread or to libmyOwnThreads. Maybe the workaround for now is to make the symbols in libXThrStub.so weak? They *are* weak Terry. The problem is that every bloody definition is weak so the linker has no way of picking the one definition which will actually work. The real problem is that the actual working threads library doesn't provide strong symbols to allow it to override all the other stubs. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
Doug Rabson wrote: You can't have a library that's sort of threaded and sort of not threaded: pick one. Yes you can - libX11 is *thread safe* but doesn't create threads. When a real pthreads implementation is present, libX11 uses its implementation of mutex, cond etc. to ensure its own safety. If the application doesn't link to a real pthreads implementation, it uses no-op stubs instead. I'm still not understanding; you say that it's thread-safe, but mutex, cond, etc. are not, in fact, thread-safe. Why aren't the libc_r implementations overriding the do-nothing implementations? The entire point of weak vs. strong symbols is that the first strong symbol wins over any weak symbols. It seems to me that you are saying there is a linker recursion problem that is not being correctly addressed because no one wants to admit there is a problem. I guess my question is: if this is all so wrong, how is it that it doesn't fail on Solaris, which does the same thing? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
Doug Rabson wrote: For what its worth, doing this (defining strong pthread_* symbols in libc_r) makes everything work fine, with or without libXThrStub. No, this would be bad. There's some justification for not doing this, in allowing programs linked againts libraries linked against threaded libraries to link against alternate threads libraries. If the symbols are stong, then this is not possible. Wrong. Either link the app to libc_r or to libpthread or to libmyOwnThreads. NO. If you have a library that's linked to a library containing string symbols, then no other library gets a chance to replace to symbols with its own strong symbols. The first strong symbol always wins, and the search is defined to be depth-first. Maybe the workaround for now is to make the symbols in libXThrStub.so weak? They *are* weak Terry. The problem is that every bloody definition is weak so the linker has no way of picking the one definition which will actually work. The real problem is that the actual working threads library doesn't provide strong symbols to allow it to override all the other stubs. First strong/last weak should win. You are saying last weak is not winning. That's a linker bug. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
* De: Terry Lambert [EMAIL PROTECTED] [ Data: 2002-10-30 ] [ Subjecte: Re: [PATCH: libc]Re: gnome on current ] Maybe the workaround for now is to make the symbols in libXThrStub.so weak? They *are* weak Terry. The problem is that every bloody definition is weak so the linker has no way of picking the one definition which will actually work. The real problem is that the actual working threads library doesn't provide strong symbols to allow it to override all the other stubs. First strong/last weak should win. You are saying last weak is not winning. That's a linker bug. Considering that I built the same applications and ran the same applications fine a while ago, and we've had a binutils upgrade, and things don't break on other systems, I'm inclined to assume there are linker bugs afoot, and all the other speculative stuff seems to be based on misunderstandings or bad information. juli. -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Wed, 30 Oct 2002 15:51:48 -0800 Terry Lambert [EMAIL PROTECTED] wrote: NO. If you have a library that's linked to a library containing string symbols, then no other library gets a chance to replace to symbols with its own strong symbols. The first strong symbol always wins, and the search is defined to be depth-first. You are ignoring the fact, that objects, loaded at the application startup time are getting searched first, followed RTLD_GLOBAL objects, and finally by the loaded object DAG. LD_PRELOAD objects override them all. First strong/last weak should win. You are saying last weak is not winning. That's a linker bug. If last weak will win, the normal case when Xthrstub is loaded _after_ libc_r will break. The only way to really fix this is to export pthread_ symbols as strong in libc_r. Exporting them as weak sounds like is a mistake which should be fixed. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Wed, 30 Oct 2002, Doug Rabson wrote: On Wed, 30 Oct 2002, Terry Lambert wrote: You need to link the library against libc_r.so instead of libXThrStub.so. Probably not. Doing that breaks the existing 'feature' of being able to use X11 in entirely non-threaded programs. I'm not sure whether that is acceptable. It also stops programs from being able to select between several thread implementations, of which -current has two. I think the only sensible solution to this problem is for libraries which provide an actual pthreads implementation (rather than a set of stubs) to define strong symbols. Wierd debugging wrappers can still be achieved via some dlopen/dlsym hackery. I don't really like this. It should be possible to have the same type of implementation as Solaris. How does X11 work for them? -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Wed, 30 Oct 2002, Alexander Kabaev wrote: On Wed, 30 Oct 2002 15:51:48 -0800 Terry Lambert [EMAIL PROTECTED] wrote: NO. If you have a library that's linked to a library containing string symbols, then no other library gets a chance to replace to symbols with its own strong symbols. The first strong symbol always wins, and the search is defined to be depth-first. You are ignoring the fact, that objects, loaded at the application startup time are getting searched first, followed RTLD_GLOBAL objects, and finally by the loaded object DAG. LD_PRELOAD objects override them all. First strong/last weak should win. You are saying last weak is not winning. That's a linker bug. If last weak will win, the normal case when Xthrstub is loaded _after_ libc_r will break. The only way to really fix this is to export pthread_ symbols as strong in libc_r. Exporting them as weak sounds like is a mistake which should be fixed. I disagree. See Solaris 6, 7, 8 9 for an example. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Wed, 30 Oct 2002 22:25:12 -0500 (EST) Daniel Eischen [EMAIL PROTECTED] wrote: If last weak will win, the normal case when Xthrstub is loaded _after_ libc_r will break. The only way to really fix this is to export pthread_ symbols as strong in libc_r. Exporting them as weak sounds like is a mistake which should be fixed. I disagree. See Solaris 6, 7, 8 9 for an example. Cool. Then let's be consistent and follow Solaris all the way. Libc on Solaris provides full set of pthread_? functions which in turn call weakly defined _pthread_?? counterparts. libpthread in turn provides strong definitions for _pthread_??. Since in absolute majority of cases libc is the first library searched for symbols, all pthread references will be bound to it and failure described by Doug will not happen. Any library providing strong pthread_ definitions will be able to override ones provided by the system. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
Alexander Kabaev wrote: If last weak will win, the normal case when Xthrstub is loaded _after_ libc_r will break. The only way to really fix this is to export pthread_ symbols as strong in libc_r. Exporting them as weak sounds like is a mistake which should be fixed. You people keep saying this, and yet the code keeps working on Solaris. Either FreeBSD or Solaris has it wrong, and since the code works on Solaris... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
