From owner-freebsd-threads@FreeBSD.ORG Wed Apr 30 16:35:10 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE86A37B401 for ; Wed, 30 Apr 2003 16:35:10 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA88843F85 for ; Wed, 30 Apr 2003 16:35:09 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h3UNZ8Bg026221; Wed, 30 Apr 2003 19:35:08 -0400 (EDT) Received: from localhost (eischen@localhost)h3UNZ7T0026217; Wed, 30 Apr 2003 19:35:08 -0400 (EDT) Date: Wed, 30 Apr 2003 19:35:07 -0400 (EDT) From: Daniel Eischen To: Peter Wemm In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: Question about rtld-elf. Anyone?.. Anyone? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2003 23:35:11 -0000 On Wed, 30 Apr 2003, Daniel Eischen wrote: > On Tue, 29 Apr 2003, Peter Wemm wrote: > > One way I've seen is to have libc and the respective pthreads libraries > > provide the public access to things like dlopen() etc. That way, the > > threads package of your choice does its own serialization of the entry > > points into the dynamic linker guts/internals. As John Polstra said > > earlier, he has some thoughts about how to make the actual lazy symbol > > lookup be thread-safe. > > I think this would work. It could even be done in our libc, just > as malloc, stdio, and friends use locking stubs (overridden by our > threads libraries). > > > If I recall correctly, our old a.out based shared lib implementation did it > > precicely this way. dlopen() was a function in libc, that called through > > a vector into the guts of ld.so.1. The dynamic linker itself never provided > > direct call access to this stuff. Some systems put these public functions > > in a seperate library, -ldl. The ELF implemetation that we use does, and > > doesn't give the threads library a chance to wrap them. > > > > (And no, this is not an invitation for getting sidetracked on making > > ld-elf.so.1 into libdl.so.1 as a service library, etc etc) > > > > How would things go if we renamed the ld-elf.so functions to __rtld_dlopen() > > etc and then had libc provide a weak dlopen() function that redirected to > > __rtld_dlopen(), and give libpthread a chance to provide a replacement? > > And of course, deal with making the runtime symbol resolution as John > > suggested in the commit logs. > > Or just have libc provide the necessary locking so that we don't need > to repeat it in libc_r, libthr, and libpthread. > > Is a simple mutex around dlopen, dlsym, etc, sufficient? We don't need > to handle recursive calls, right? As an experiment, I made the dlfoo calls in rtld-elf weak (__dlfoo -> dlfoo) and then overrode them in libpthread and protected them with mutexes. I can get mozilla to work about 1/2 of the time now, but it still gets stuck in the same state the other 1/2 of the time. This is a bit of an improvement, and seems to indicate (at least to me) that rtld-elf is the culprit. -- Dan Eischen