Date: Tue, 29 Apr 2003 22:41:48 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Peter Wemm <peter@wemm.org> Cc: Daniel Eischen <eischen@pcnet1.pcnet.com> Subject: Re: Question about rtld-elf. Anyone?.. Anyone? Message-ID: <3EAF621C.E59B1AD5@mindspring.com> References: <20030430045926.40FD82A7EA@canning.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Wemm wrote: > Narvi wrote: > > Well, i think we should gurantee something about the sanity of libc > > internals to the forked process. > > This is getting a bit sidetracked here. Remember the issue at hand > is how to protect the ld-elf.so.1 internals in a pthread context. Not > how to recover from a fork(). > > 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. This is actually hard to do, given the way that the ld.so gets mapped in and referenced by the crt0 code. I don't actually know if it would even be possible, even with two levels of weak symbol indirection. One really hard problem is a statically linked threaded program still trying to override the symbols with weak references to things that aren't there (hence the two levels of indirection). One of the "magic" things that's assumed in the SUS, and by the X/Open and POSIX codification of SVR4 behaviour as "correct UNIX" (be honest: that's what those standards are) is that there is a "reserved" low end memory range, well below the link address of user programs. This is actually used for the *kernel* to map the ld.so into the process address space on the processes behalf; it's why there's a dlopen() available in static binaries on SVR4. This change is pretty radical, from a BSD perspective, not the least of which because of the base address space having to be prereserved, but it would certainly solve the problem. > 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. Yes. Now it's referenced through the crt0 stuff; this happened when we did a compiler and tools import, and changed to "the GCC way" of doing things, in the great ELF switchover. In many ways, I miss a.out: ELF has failed to have its capabilities used to a reasonable extent (pageable code and data sections in the kernel, etc.). 8-(. > (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. You would need two weak references, one of which was a weak reference to the "real" reference (the "fake" functions in the non-dynamic case), and the other which was a weak reference to the weak reference, to let the libc_r (or whatever) override the libc reference. Last time I checked my linker-foo, there was a problem with doing this in GCC (it caused a library link error in Archie's work on the Kaffe JNI code, while using dlopen; the only fix was to statically link an intermediate library that had the middle symbols in it; maybe this could be jammed into the crt0 code). -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EAF621C.E59B1AD5>