chuck@morgan.com (Chuck Ocheret) (05/29/90)
I,ve read the discussion of shared libaries and the man pages for dlopen(), dlsym(), etc..., ld, a.out and more and have still not resolved the proper way to accomplish dynamically loading object code into an executing process. Here is how I do it under 4.0.x: 1. Create the .o file that I want to dynamically load in. 2. From the running process run ld with the -A option for incremental loading. This gives me the size of the incremental a.out file. 3. Allocate space for the a.out file. 4. Run ld -A again to relocate the a.out file to the allocated space. 5. Read the a.out file into the allocated space. 6. Invoke nlist(3) to get addresses of entries in the symbol table. The problem with this under 4.0.x is that I have to link statically and I have to link twice. Does anyone have a recipe for how to do this under 4.1. I am hoping to avoid the time-consuming double static link. Please e-mail directly to me and I will summarize. I will also post the code that results for the information I receive. Thanks, +------------------+ Chuck Ocheret, Sr. Staff Engineer +-----------------+ | chuck@Morgan.COM | Morgan Stanley & Co., Inc. | (212) 703-4474 | | Duty now ... |19th Floor, 1251 Avenue of the Americas| for the future. | +------------------+ New York, N.Y. 10020 USA +-----------------+
chuck@morgan.com (Chuck Ocheret) (05/30/90)
> From: uunet!tapir.Caltech.EDU!edelsohn (David Edelsohn) > SunOS 4.1 is suppose to have routines such as dlopen() which should > provide runtime dynamic linking without /bin/ld -A on static programs. I > have not seen the details yet and I am interested in finding out. The game > should be to "cc -pic" the subroutines and then map them in with dlopen(). > This should provide user-mode access to the kernel dynamic linking/loading > facilities which previously required the routine to be in a shared library > known to the system prior to running the executable image. > David The thing missing from dlopen() is that it does not resolve symbols in my .o (pic or not) file (as far as I can find in the manuals). If I have a call to printf() in a .o file which I want to dynamically load in after my process is running, how does printf()'s entry point get resolved with SUN's shared libraries? Must I manually look through the .o symbol table and attempt to find the modules in the various shared libraries? What order do I use to search the libraries? On the man page for dlopen(3), there is a mention of a -ldl option to ld (I assume this means there is a libdl.a) which, I suspect, provide routines for accomplishing such binding (init() and fini()). However, I cannot find any specific mention of them anywhere else in SUN's documentation, including the Global Index. ~chuck
glenn@uunet.uu.net (Glenn Gribble) (06/05/90)
There is another way to do dynamic loading: DESCRIPTION This is a dynamic loader for Sun3 and Sun4. The interface is very simple. There are three main functions: setArg0(const char *) - Call with argv[0] to find main object file bool loadFile(const char *fileName) - Load an object file long value(const char *sym, int bad=-1) - Find symbol value This loader reads the object file into memory and does the relocation on its own. This makes it fast and it works even if the main object file is dynamically linked (the loaded object file can make calls into the shared libraries). The advantages of this loader over SunOS 4.1 dlopen() or "ld -A": 1) Works with normal object files (does not use shared libraries) 2) Works if the main object file is dynamically linked. 3) Loaded object can have symbol dependencies into main file or previously loaded object files. 4) It is much faster than the "ld -A" approach. The disadvantage: 1) It will not load every type of file since I have not found ways of making all relocation types in Sun object files. Other things to note: 1) It is written in C++. 2) It is free and unsupported (although I would like to hear of bugs). Glenn Gribble glenn@synaptics.com uunet!synaptx!glenn Synaptics, Inc. (408) 434-0110 2860 Zanker Road, Suite 105 (408) 434-9819 FAX San Jose, CA 95134 [[Ed's Note: Source placed in archives. -bdg]] FTP: Hostname : titan.rice.edu (128.42.1.30) Directory: sun-source Filename : dynload.shar Filesize : 23435 bytes Archive Server Address: archive-server@rice.edu Archive Server Command: send sun-source dynload.shar
guy@uunet.uu.net (Guy Harris) (06/07/90)
>The advantages of this loader over SunOS 4.1 dlopen() or "ld -A": > >2) Works if the main object file is dynamically linked. Umm, are you asserting that "dlopen()" *doesn't* work if the "main object file" (by which I assume you mean the main executable image) is dynamically linked? As far as I know, that's not true....