Date: Fri, 16 Oct 1998 20:23:13 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: shmit@kublai.com Cc: mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: ELF object file aggregation Message-ID: <199810162023.NAA25648@usr04.primenet.com> In-Reply-To: <19981016144738.H19804@kublai.com> from "Brian Cully" at Oct 16, 98 02:47:39 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > I'm working on a project that requires the functionality of dlopen() > > > and friends, but I want to link it statically. I was thinking that > > > I could do this by munging together various ELF files at run-time > > > and scarfing symbols (the way kldload does things, if I'm not > > > mistaken). > > > > Do you want it to be statically linked, or do you want it to not have > > external shared library dependancies? There's a big difference. 8) > > I don't want external shared library dependencies. Basically, I'm > working on a replacement for /etc/rc, so I can't rely on > /usr/libexec/ld-elf.so or any of the libs in /usr/lib. > > It seems to me like run-time object file aggregation was the optimal > solution. The way dlopen works is by way of calling routines in ld.so. The way ld.so works is by way of symbol offsets known to the code stubs in crt0.o. Probably the correct thing to do with ELF is to put ld.so in /sbin or /libexec, or even in a kernel module (i.e., .ko). The ELF binary format includes an intentional hole for ld.so between the end of the first page and the first address in memory (I believe this hole is technically both for ld.so AND for a shared libc). The execution class loader is supposed to default process memory mappings from a template memory map. In that template, the ld.so is mapped into the process address space by the execution class loader, and *NOT* through the actions of an ld.so. In other words, on an ELF system, it is *expected* that the ld.so (and, I believe, the libc.so) will always be present in the process address space, with a jump table at a known offest in the mapping. Basically, this means that dlopen and libc functions are *always* available, and that fixups aren't required to be implemented in the crt0.0 code. For SVR4 systems, the mapping is actually after the page after the first page, to allow the first page to be mapped zero filled so that it will be impossible to debug NULL^W^W^W^W^W^W you can run legacy code. The idea that the default system binaries should not be linked against shared libraries is an old superstition having to do with not wanting to locate shared libraries on the / partition, because that takes up space, but statically linked copies of libc don't, uh, er, because depending on ld.so not getting corrupted is very different than depending on /bin/sh not getting corrupted, uh, er, uh... uh... because we say so! Quit asking so many difficult questions! 8-). In any case, if you look at crt0.o, it's pretty obvious where the jump table entries are and what they refer to, so it's rather simple to write a statically linkable glue library whose ctor list includes mmap'ing ld.so form somewhere on / (/libexec?) and this will give you the dlopen/et. al. calls in a static binary for a few minutes of .s and .c file hacking. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810162023.NAA25648>