nieh@nnn.crd.ge.com (09/15/89)
This idea just came across to my mind. If it is feasible it would be
very useful. Before I even try it I would like to get some opinions.
On SunOS 4.0,
1. run a C program which generates a C function, say xxx(...).
2. fork a cc to compile it and to put it into the shareable library.
3. back to the program and call it. (I think it's ok)
4. generate a different version of xxx(...)
and compile it and put it back to the same shareable library.
5. call it again. (what should happen? the old xxx(...)
or the new xxx(...) gets executed ?)
Any comments ?
--
Ko-Haw Nieh
General Electric Company | nieh@crd.ge.com
Corporate Research and Development | uunet!crd.ge.com!nieh
P.O BOX 8, K1-ES224 | FAX : 518-387-7258
Schenectady, NY 12301 | TEL : 518-387-7431 natei@sco.COM (Nathaniel Ingersoll) (09/16/89)
In article <NIEH.89Sep14164443@nnn.crd.ge.com> nieh@nnn.crd.ge.com writes:
:
:
:This idea just came across to my mind. If it is feasible it would be
:very useful. Before I even try it I would like to get some opinions.
:
:On SunOS 4.0,
:
: 1. run a C program which generates a C function, say xxx(...).
: 2. fork a cc to compile it and to put it into the shareable library.
: 3. back to the program and call it. (I think it's ok)
: 4. generate a different version of xxx(...)
: and compile it and put it back to the same shareable library.
: 5. call it again. (what should happen? the old xxx(...)
: or the new xxx(...) gets executed ?)
:
:Any comments ?
This wouldn't work because you wouldn't be able to write to the shared
library that your program includes, because it's currently loaded
in memory (sort of like "Text file busy"). An analogy would be
writing to the text file of your program and having that
modify the data/text of your running program, which also doesn't work.guy@auspex.auspex.com (Guy Harris) (09/17/89)
>This wouldn't work because you wouldn't be able to write to the shared >library that your program includes, because it's currently loaded >in memory (sort of like "Text file busy"). Wanna bet? You *can* write to a SunOS shared library that's mapped into memory - I know, I've done it, although not deliberately. (Hint: don't assume the SunOS shared library mechanism is derived from the S5R3 one - it's not. The S5R4 one is derived from the SunOS one, though....)
sja@cs.purdue.EDU (Srinivasan Jagannathan) (09/17/89)
The summary of what net thought of how dynamic loading can be done
on Sun3s, Sun4.0 OS.
1. Sun4.0 OS DOES dynamically loading of libraries (option -Bdynamic).
Thus while linking the loader just remembers the path name of the libraries and
dynamically loads the needed routines DURING THE EXECUTION OF THE PROGRAM.
Btw the default option is -Bdynamic. If you wish static loading -Bstatic
option should be used.
2. This however does not solve the application I have , which requires
dynamic loading of object files during execution and call arbitrary
functions ( decided during the execution time) from them. That is I
don't have function calls embedded in the code to exploit features
discussed in 1.
3. SUN4.0 OS comes with incremental loading option (-A) which allows
one to create a object file based on the symbol table of another a.out.
The resulting object file uses incremental loading to avoid loading routines
which are already resolved in symbol table of the referenced a.out.
Strategy for dynamic loading
----------------------------
Let
dl.c : code for dynamic loader (dl is corresponding binary).
dobj.o : object file which has to be dynamically loaded.
d : variable which contains the name of function to be executed.
step1: cc -Bstatic dl.c -o dl.
Note -Bstatic flag used to force resolving of all external references
and to statically include code for all external references.
dl.c:
-----
loadfile("dl.o");
fn=findsymbol(d);
(*fn)();
loadfile(objname)
1. valloc huge area
p=valloc(huge area);
2. Use system command to build robjfile as follows
sprintf(cmd,"ld -A %s -T %x -Bstatic -dc -dp -X %s -o %s -lc",dlfname,p,
objname,robjname);
system(cmd);
Note: robjname will have code loaded incrementally w.r.t symbol table of
dlfname. T option is used to start the text segment at address
correspondng to p. Finally static laoding option is used.
3. Copy the file corresponding to robjname into data area starting at p.
4. Copy symbol table to some structure, and return the pointer.
findsymbol(pointer,name)
1.reference symbol table using pointer and return address of symbol
corresponding to name.
Other suggested strategies
--------------------------
1.Build a beast which almost does the work of the loader.
2.Use nm and grep for findsymbol avoiding need to maintain symbol table for
loaded object files.
If you are interested in actual code please send me mail.
Jags
sja@cs.purdue.edu
--
Jagannathan Srinivasan
{ucbvax,decvax,hplabs}!purdue!sja -or- sja@cs.purdue.eduguy@auspex.auspex.com (Guy Harris) (09/19/89)
>1. Sun4.0 OS DOES dynamically loading of libraries (option -Bdynamic). >Thus while linking the loader just remembers the path name of the libraries >and dynamically loads the needed routines DURING THE EXECUTION OF THE PROGRAM. Well, dynamically links them, anyway. The libraries are mapped into the address space of the process at program start-up time; the run-time loader is run from the C start-up code. >2. This however does not solve the application I have , which requires >dynamic loading of object files during execution and call arbitrary >functions ( decided during the execution time) from them. That is I >don't have function calls embedded in the code to exploit features >discussed in 1. Correct. 4.0 doesn't have a way for a program to call the run-time loader to get it to map a library in at run time or, given a "handle" for a mapped-in library and a string that represents the name of a function in that library, return a pointer to the function in question. I expect SunOS 4.1 and S5R4 to have calls to do that. >3. SUN4.0 OS comes with incremental loading option (-A) which allows >one to create a object file based on the symbol table of another a.out. >The resulting object file uses incremental loading to avoid loading routines >which are already resolved in symbol table of the referenced a.out. This actually comes from 4.xBSD (was it introduced there for the benefit of Franz Lisp?), so it may be available on other systems as well.
lupton@uhccux.uhcc.hawaii.edu (Robert Lupton) (09/19/89)
Re: ld -A, I've never managed to figure out how this works. I've read the man page periodically over the past few years, but never needed to do it for real (still true!). Does anyone have an example of how to use -A to dynamically load a subroutine into an executable? Mail, please, with a summary if there's interest. Robert