Date: Wed, 7 Aug 2002 14:35:18 -0400 (EDT) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: John Polstra <jdp@polstra.com> Cc: hackers@freebsd.org Subject: Re: Help needed. Deadlock in rtld makes openoffice build hang ag Message-ID: <Pine.GSO.4.10.10208071419280.18290-100000@pcnet1.pcnet.com> In-Reply-To: <200208071753.g77Hr6Fs058407@vashon.polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 7 Aug 2002, John Polstra wrote: > In article <200208071636.g77GavpD003986@mail.pcnet.com>, > Daniel Eischen <eischen@pcnet1.pcnet.com> wrote: > > > I agree completely about spinlocks vs. mutexes, in principle. But ... > > > the reason the rtld uses its own spinlock implementation is because > > > it cannot assume that the threads package is libc_r. It could be > > > linuxthreads or some completely unknown threads package. I don't > > > like the current solution in the rtld, but it's hard to come up with > > > something that works with arbitrary threads packages. > > > > As long as all threads packages that we want to support have > > pthread_mutex_lock/pthread_mutex_unlock, then you can just > > use a weak reference to them (and pthread_mutex_init I guess > > too) and use them when present. > > I tried something like that once, but I ran into a problem. When the > rtld calls one of the application's locking functions, that function > might reference a symbol which needs lazy binding. That results in > a call back into the rtld, and the rtld locks against itself. I > guess it's worthwhile revisiting that approach and trying harder to > make it work. Hmm, I didn't think of that. I know early in the libc_r/libc breakout in -current, we had problems with static libraries, where libc needed (weak referenced) things in libc_r, but the application didn't make use of some of those functions so they were missing in the statically built executable. For instance, if libc needs pthread_getspecific but the application never references it, it never gets built into the static image but libc is going to try and use it because __is_threaded is non-zero. So to solve this problem, we placed all references that libc needs in uthread_init.c. Everything in the threads library needs uthread_init, so it gets linked in and forces all the other needed things to get linked in also. You could also do something similar, forcing inclusion of needed symbols, but never using any of them (pthread_mutex_lock) unless they were all present. This seems pretty ugly though. You could just use __isthreaded for our own libc_r, because by the time that is set, all of our needed symbols have already been loaded. But that doesn't work for linuxthreads. I suppose we could require all threads libraries to set this and to ensure that all the necessary locking primitive symbols have been resolved before it is set. This would require a fix to libc_r because __isthreaded is set at the beginning of pthread_create and it would need to be set at the end. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10208071419280.18290-100000>