Date: Mon, 31 Mar 1997 13:59:25 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: phk@critter.dk.tfs.com (Poul-Henning Kamp) Cc: wollman@khavrinen.lcs.mit.edu, terry@lambert.org, freebsd-current@FreeBSD.ORG Subject: Re: A new Kernel Module System Message-ID: <199703312059.NAA10110@phaeton.artisoft.com> In-Reply-To: <27686.859838573@critter> from "Poul-Henning Kamp" at Mar 31, 97 10:02:53 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Question: If we stick the linker in the kernel, doesn't it mean that > we could use it for shlibs too ? Probably. I've felt for a long time now that the intent of the memory hole at the start of the executable in the ELF SVR4 EABI was to allow the mapping of the ld.so into the process address space without there being code in crt0.o to actually do the work. > Basically the dl* functions could be made syscalls couldn't they ? Or section (3) wrappers for mmap. I don't know how you would deal with the issue of dlsym(), but you'd want to do it in such a way that it didn't matter if the vtable reference was ELF, COFF, a.out, or whatever. That may imply a system call for kernel decoding the format specific symbol information. The big hairy question mark there is how to handle library static data and per thread replication, etc.. I'd like to see it instanced per link instead of crammed into the image as static data. That would resolve a number of my LGPL misgivings about dynamic linking. I don't know how you would make the compiler generate the slower PIC references to the data in that case, and NOT do it in all cases. > That would be way faster than mmap'ing ld.so all the time... Unless the kernel did the mapping and the ld.so was (effectively) a piece of the execution class loader, as a result. The difference, I suppose, is where the r/o mappings for the linker code originated, and whether they were in the process address space, or whether you had to cross a real protection domain to get them. I'd almost prefer they stay in the process address space (trading startup speed in favor of runtime speed). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703312059.NAA10110>