ITEM: P4398L

How to resolve symbol references at runtime

Question:

E:  AIX 3.2.5, shared objects, linking

D:  I want to build a shared library object that will call some
of the functions which are available in some other libraries. Now, why
should I have to link all the libraries with the shared library? As long
as all symbols get resolved at execution time, the program should
run. Is it possible to defer linking other modules until run time? I
know if I put all the modules as shared library, I could do that. But
there is  a performance penalty in making a function call to a shared
library function.

A:  There are a few fine points that must be addressed.  In fact, not
all functions must be available at link time to produce a valid and
loadable object module.  By using either (a) an anonymous import list
(first line is '\#!') or (b) using the -berok ld option, you can leave
symbols for resolution during program execution.  As long as your
running program does not attempt to access any unresolved symbol,
execution will continue without problem.  To complete resolution at
runtime, you'll need to make an explicit call to loadbind(),
specifying the exporting and importing objects for the symbols in
question.

If your desire is to resolve shared object references against symbols
provided by a main application, then do the following:

   1) create your shared object specifying unresolved symbols via
anonymous import lists or the -berok option.  Note that -berok does
not work for data structure references, only function references.

   2) Create your main application, exporting the symbols of interest
via an export list and the -bE:\ option.  This makes the
symbols publicly available to other objects (at runtime).

   3) Call loadbind() from within your application to resolve symbol
references (in the shared object) to symbol definitions (in the main
application). Refer to the documentation for information on the
function arguments; any symbol name, or the value returned by load(),
is valid to specify the importing or exporting object.

As for the question of a performance penalty: there is a 9 cycle
overhead for every call to a function outside of the current object.
For functions that are within the same object, a branch instruction is
used that has very little overhead.  Since this overhead exists for
every object-to-object jump, your use of shared objects is no
different than any other on the system.  The overhead is consistent.



Support Line: How to resolve symbol references at runtime ITEM: P4398L

Dated: June 1996 Category: N/A

This HTML file was generated 99/06/24~13:30:38

Comments or suggestions?
Contact us