This sounds like an MVS facility. Any executable can be loaded into the
address space (process). You get the load address & the entry point address
IIRC. It's very useful for dynamically loading subroutines which may not
be needed for every execution, or executing a system utility, like the
assemble or a compiler on the fly. Another use is to load a table which
can be changed without re-building the entire application. MVS lacks
anything remotely like make so these tend to be important uses.
I think he needs to re-design what he's doing to fit into the shared
library structure of Linux.
> Get the address of what, specifically, and how do you expect to use it.
> A shared object has init and termination code which are just normal
> procedures and after init the shared object just sits there waiting for some
> function within it to be called. An executable starts and does not stop
> until it terminates itself. Given the above... what does the system loader
> do when loading an executable via dlopen. I do not know. Does anyone else?
> Calling something not exported is dangerous since the author of the shared
> object can do anything they want without regards to standards beyond the
> public interface to the shared object.
> If the symbols you want is not exported (in the .dynsym section), then if
> the shared object has a symbol table the symbol will most likely be there.
> This means you will have to parse the executable image file, and adjust the
> symbol address retrieved from the symbol table to the loaded address of the
> image loaded after calling dlopen.
> Norman Black
> Stony Brook Software
> the reply, fubar => ix.netcom
>> Okay, dlopen looked to be pretty helpful, until I discovered that the
>> symbols one can find (via dlsym calls) all have to be exported symbols.
>> The load subroutine call in AIX simply loads the executable and points
>> to the first loaded text address. The dlopen call seems to load the
>> executable to somewhere, and return a cryptic handle that I cannot figure
>> how to use to get back to something with physical meaning, unless I
>> recompile the object I want to dlopen and export some symbol I'd like
>> to dlsym. I don't think this is possible as I don't have access to the
>> code to recompile this executable, and I have not found a run-time
>> routine in the linux world that would allow me to do this.
>> Thus, does anyone know how to get either the address at which the
>> is loaded (from dlopen, I think I can then work around other problems) or
>> to get a non-exported symbol, OR to relink an executable to make something
>> (e.g. main) an exported symbol so dlopen and dlsym will be helpful?
>> IBM T. J. Watson Research Center phone: 914-945-2523
>> P.O. Box 218, Yorktown Hts, NY, 10598 fax: 914-945-4469