Question about rtld-elf. Anyone?.. Anyone?

[Daniel Eischen]

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