Date: Wed, 30 Apr 2003 13:48:13 -0400 (EDT) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: Peter Wemm <peter@wemm.org> Cc: threads@freebsd.org Subject: Re: Question about rtld-elf. Anyone?.. Anyone? Message-ID: <Pine.GSO.4.10.10304301342140.29023-100000@pcnet1.pcnet.com> In-Reply-To: <20030430045926.40FD82A7EA@canning.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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? -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10304301342140.29023-100000>