Date: Thu, 14 May 1998 19:19:02 +0800 From: Peter Wemm <peter@netplex.com.au> To: Terry Lambert <tlambert@primenet.com> Cc: jb@cimlogic.com.au (John Birrell), current@FreeBSD.ORG Subject: Re: dlopen again Message-ID: <199805141119.TAA16336@spinner.netplex.com.au> In-Reply-To: Your message of "Thu, 14 May 1998 06:36:52 GMT." <199805140636.XAA22124@usr05.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote: > What are the current obstacles to having a dlopen that works in > statically linked code? libc.so.*.* Specifically, if you have a static binary that doesn't make a call to (say) socket(), then socket() isn't linked into the image. If you then call dlopen() and call something in there that wants to call socket(), you then have an undefined symbol. Linking the dlopened module with libc.so.* explicitly also fails since you have two different malloc() pools. All the libc.so routines are internally linked directly to the internal malloc, while the calling program has it's own version. Passing a malloc pointer obtained from (say) strdup() within libc to the static version of free() == death. However, the elf ld.so has got full weak symbol support so this can be avoided. Basically you can have libc.so provide malloc() if it's missing, and the internal calls to malloc within libc are attached to the weak symbol which will resolve to the malloc in the static binary if it's present. This completely resolves the problem and would allow a static binary to dlopen() something that dynamically depends on libc.so.x. > Specifically, it seems very useful within the context of the NIS+, > the LDAP, PAM, and the new resolver libraries, to be able to > configure .so's, either by name or by mere existance in a subdirectory > of libexec, as pluggable service providers in a library. > > I've been thinking about this for generic versions of the inet(3) > functions, as well, with an eye towards ISO and AX.25 support as > drop-in modules. The system is crying out for this sort of thing in certain areas. However, one has to be careful to not go too far overboard. Forcing all getpwnam() calls to go via a dlopen() would not be a wise move, however there is nothing wrong with having an extensible (and overrideable) table in libc. You could compile libc with file (and dns) support, and allow YP/ NIS/NIS+/HESIOD/etc support to be loaded via dlopen(). Or choose to statically compile the lot if that pleases you. Linker sets can help here in a.out format, and the elf sections would help orgnaize this under elf. > It seems to me (and always has) that the hole at the front of an ELF > binary, but after page zero, was intended to have ld.so mapped into > it by the kernel (and *not* map ld.so in crt0.o). The kernel does map the ld.so for us under elf. The elf crt0.o does very little compared to the complex a.out crt0.o. > Terry Lambert > terry@lambert.org Cheers, -Peter -- Peter Wemm <peter@netplex.com.au> Netplex Consulting To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805141119.TAA16336>