Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!brl-adm!adm!bzs@bu-cs.BU.EDU
From: bzs@bu-cs.BU.EDU (Barry Shein)
Newsgroups: comp.unix.wizards
Subject: Dynamic function loading
Message-ID: <6942@brl-adm.ARPA>
Date: Fri, 17-Apr-87 00:25:21 EST
Article-I.D.: brl-adm.6942
Posted: Fri Apr 17 00:25:21 1987
Date-Received: Sun, 19-Apr-87 10:11:40 EST
Sender: news@brl-adm.ARPA
Lines: 67


Responding to some notes by Garry Wiegand
>- There's no way to get more than 65K bytes at a time from K&R-standard
>  malloc(). You have to mess with sbrk(), I guess. There's a tickle in
>  my brain which says "don't call sbrk yourself if you want the run-time
>  library not to get confused."  Is my tickle true on some systems?

I don't believe this is a limit (65KB/malloc, max) on any malloc()
that's been written on a 32-bit machine. Obviously on a PDP-11 it
would be true due to architectural limitations, but the object code
you are loading had better reflect that (note that with dynamic
loading you can effect an overlay linking by swapping in/on object
code in the same area and artificially extend the text space beyond
any architectural limit.)

I'm sure *one* such malloc() exists, a better malloc can be written,
maybe there's even one available (I think there's one inside GNU Emacs.)

>- How do you fix up the relocations in the image you're bringing in? Or
>  do you link it at an absolute address? (ick)

This is how it all started. You do a system("ld -A xyzzyx foo.o") or
equivalent (eg. fork/exec) where xyzzyx is determined at run-time
(what the malloc returned.) You can either do this when you are about
to load it (it's quite fast on most machines) or you can re-locate all
your object decks as part of the make process and pre-assign a table
which indicates where these things are to be located (also has to be
re-done each time the objects are re-built, I just added a -L foo.o
flag to the command line which would re-build decks, but it's not
necessary, do it at load-time.)

>- What do you do on machines with separate Instruction/Data spaces?

I'll be flippant: throw them away and replace them with a $1500 Atari
system with 1MB of memory (ok, ok, but it can be done, I forget how,
I believe my PDP11/45 at Harvard Chem had an overlay linker under V7,
my memory could fail me.) You get what you pay for.

>- Does a.out.h tend to be quite similar or quite different on different
>  systems?

You can get *reasonable* portability (look at the GNU Emacs unexec()
routines that rely on this and manage COFF and 4.2 on many different
systems.) The routines that are sensitive to this format would probably
be less than 100 lines of code, they can be re-written for each port.
It's mainly a matter of extracting the portable and non-portable parts
of the code. Remember, this is self-made magic, expect some portability
problems. By and large there's COFF and 4.2 and that's about it although
you'll run into slight aberrations if you port it to enough systems.

Garry, do you realize the reason I am answering this is because I
delivered a running system like this to ComputerVision a short while
back? I can't send the code because I don't own it. Also, the reason
people seem to find this hack is because that's how Franz Lisp works.

Yes, your scheme works fine, I had implemented that as well as the
table driven method (declaring a subroutine for each and having it
load if necessary and jump to the routine.) The other observation was
that you can write a program which builds all the stubs automatically
from the symbol tables at Make time. It can actually just be a
post-processor to nm written in awk, no need to do any serious
object deck groveling.

If you want a code example I suggest Franz Lisp. The fasload stuff
is fairly small and straightforward.

	-Barry Shein, Boston University