Return to BSD News archive
Newsgroups: comp.os.386bsd.apps Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!overload.lbl.gov!dog.ee.lbl.gov!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (A Wizard of Earth C) Subject: Re: dynamic loading, anyone? Message-ID: <1993Jul26.163629.25690@fcom.cc.utah.edu> Sender: news@fcom.cc.utah.edu Organization: Weber State University, Ogden, UT References: <1993Jul25.022743.26253@husc14.harvard.edu> Date: Mon, 26 Jul 93 16:36:29 GMT Lines: 48 In article <1993Jul25.022743.26253@husc14.harvard.edu> haley@husc10.harvard.edu (Elizabeth Haley) writes: >HiHo: > >I was wondering if there was anyone out there working on a dynamic >loader for 386bsd? > >The FSF has something called dld out, but It doesn't support the i386 >in any OS... Define if you mean user space (like xtank) or kernel space (like modules). If user space, tell me if shared libs are sufficient, or if PIC'ed code hunks loaded at a particular address are what you mean. I have code for kernel space and shared libs, but can't release the shared libs code for a while (it'll probably be too late by then, and the Joerg libraries will already be in place) for political reasons. The kernel stuff is already with Bill Jolitz, the NetBSD group, and the FreeBSD group (the NetBSD and FreeBSD groups work closely enough together that a single post to a single mailinglist was sufficient). PIC'ed code hunks would be relatively easy to implement, the main problem being a lack of PIC support in the default GNU utilities. A member (?) of the NetBSD group has provided PIC changes, but not for the new GNU tools, only for the 1.39 C and family. I use these in both shared library types I have hacked. It should be relatively easy to make a PIC'ed .o after integrating these changed into your tools, then mmap the file, marking the page(s) executable, and with knowledge of how the GOT is laid out, call the functions in the "dynamically loaded" module. If, on the other hand, you are talking genuine overlay, like in DOS, you will have to make something akin to "transient-user-provided-shared-libs" and pre-resolve the symbols. This is fairly useless on a VM architecture for the vast majority of cases unless the GOT is sorted and the entry points well-defined. A shared library implementation that didn't care about "ldconfig" (thus engendering security holes) and/or mapped an absolute path for link targets (thus restricting configurability) would suffice. I won't be providing this if I finally get OK to release the shared lib stuff. Terry Lambert terry@icarus.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.