bosco%pwa-b@uunet.uu.net (Jim Bosco) (11/02/89)
Is there a way to link, at runtime, an arbitrary object file to the current process? The name of the subroutine to dynamically link is not known at compile/link time. It becomes known during execution. This object file must share the address space of the parent process. The linking should resolve external references in the object file with entry points in the current process. It appears that forking/execing a process and using the System V shared memory routines might be a work around, but is this the only solution? The program's data structures contain many pointers to malloc'ed storage. The bookkeeping to manage all of the shared memory identifiers between the processes would be a burden.
net%TUB.BITNET@mitvma.mit.edu (Oliver Laumann) (11/13/89)
In article <2885@brazos.Rice.edu> you write: > Is there a way to link, at runtime, an arbitrary object file to the > current process? The name of the subroutine to dynamically link is not > known at compile/link time. It becomes known during execution. This object > file must share the address space of the parent process. The linking > should resolve external references in the object file with entry points in > the current process. You may want to look into the `Elk' Scheme interpreter that has been posted to comp.sources.misc a couple of weeks ago. Elk contains a module that implements dynamic loading of object files into the running process (see the file src/load.c); it makes use of the -A linker option (incremental loading). If you didn't get the above-mentioned posting or have more specific questions about dynamic loading, send me e-mail. Regards, Oliver Laumann net@TUB.BITNET net@tub.UUCP
harp@terra.pkg.mcc.com (Christopher North-Keys) (11/21/89)
q> Is there a way to link, at runtime, an arbitrary object file to the q> current process? a> You may want to look into the `Elk' Scheme interpreter that has been a> posted to comp.sources.misc a couple of weeks ago. You might also look at the dynamic loader in xtank, available from expo.lcs.mit.edu (18.30.0.212) under contrib/. The code is in Src/unix.c . It also uses a threads implementation.
net%TUB.BITNET@mitvma.mit.edu (Oliver Laumann) (11/22/89)
> 1) My experience with dynamic loading is that the ld -A > requires 2 passes. The first pass allows you to determine the size > of the resultant `.o' file so that you can malloc() space. The second pass > uses the result of your malloc() for relocation of the code. This can > be very time consuming. Is there a `trick' to accomplish this in 1 pass. Yes, there is. Don't malloc() the space; use sbrk() instead. You can use the result of a call to sbrk(0) as the value for the -T option of /bin/ld and call sbrk() again after the linker has finished to really allocate the space. Of course, this is not portable, since sbrk() is not guaranteed to exist in all environments. But then, dynamic loading is non-portable anyway (e.g. your linker may not support the -A option)... Regards, Oliver Laumann net@TUB.BITNET net@tub.UUCP