When you generate a shared object, you do not have full control over where content is placed—a shared object is always linked on address 0. The shared object will always be loaded into memory, so this is just a convenient way to get the offsets and addresses. If a symbol is generated at offset 0x420 in the shared object and the shared object is loaded on 0x8000, the symbol will have the value 0x8420.

The normal place in and place at directives are not available when you generate a shared object. In a shared object, there are five blocks that must be defined using the define block directive: so_code, so_const, so_relrodata, so_data, and so_bss, see Reference information on linker blocks for shared objects.

You can use blocks in blocks as usual:

define block so_code with fixed_order {
block myFirstBlock,
block mySecondBlock,
block myThirdBlock
};

As long as you have defined all five blocks (you can define empty blocks), and your linked application does not contain any sections that do not match in any of the blocks, the shared object will have the specified layout.

When the shared object is loaded by a call to dlopen, the dynamic linker checks which symbols that the new shared object supplies and which symbols the dynamic linker requires (the undefined externals). With this knowledge of the currently loaded symbols and their addresses, the dynamic linker updates the loaded object and all previously loaded shared objects by updating the addresses in the GOT sections.

The loading can be lazy or eager. Eager loading resolves all symbol addresses at load time. Lazy loading resolves all data symbols at load time, but code symbols not until they are first accessed. The choice is typically handled through the use of a flag in the call to dlopen. All ILINK generated shared objects work with both lazy and eager loading.

A shared object is unloaded with a call to dlclose. When this happens, the symbols that the shared object supplied are removed from the system. Note that this can invalidate the environment of other shared objects that rely upon those symbols being available.

After a shared object has been loaded using dlopen, the function dlsym can be used to access content from the shared object. Refer to the documentation for the operating system you are using for exactly how this is done.

The C interface can be found in the header file dlfcn.h (not supplied by IAR).

Accessing a data variable in a shared object might look like this:

void * handle = dlopen("myObject.so", FLAGS);
int * dataPtr = (int *)dlsym(handle, "myVariable");
...
dlclose(handle);

This acquires a pointer to the symbol myVariable in the shared object myObject.so.

Accessing a function in a shared object might look like this:

void * handle = dlopen("myObject.so", FLAGS);
typedef int (*function)(int, int);
function myFunc = (function)dlsym(handle, "myFunction");
...
dlclose(handle);

This acquires a function pointer—a function that takes two int parameters and returns an int—to the function myFunction in the object myObject.so.

FLAGS is a system-dependent value that controls various aspects of loading shared objects. The choice between lazy and eager loading is typically made using this flag— refer to the documentation for the operating system you are using.