Introduction to shared objects

In this section:

Briefly about shared objects

In addition to creating executable files—files that either construct their own execution environment, or are loaded onto a running system—the ILINK linker can also generate shared objects (shared libraries).

Shared objects are loaded into the execution environment of another, already executing, process through a call to the function dlopen. Shared objects are always loaded into RAM. The loading process can then access the shared object and use its symbols.

The loading process can open several shared objects, and the shared objects can refer to each other’s exported content. Once a shared object has served its purpose, it can be unloaded and the memory it was loaded into can be reused for other purposes, including by other shared objects.

Note

Shared objects are only supported on the 32-bit Arm architecture.

Reasons for generating shared objects

Shared objects are designed to be used by multiple applications or other shared objects at runtime, under an operating system. If an application uses a shared object, the operating system loads the object from a file into memory at load time, using a dynamic linker or something that can act like a dynamic linker.

Requirements for generating and using shared objects

To be able to generate shared objects with ILINK, and to use them with your application, the following requirements apply:

Position-independent code and data

Code and data in a shared object must be able to reside anywhere in memory—it must be position-independent. For this reason the command line option ‑‑shared, that specifies shared object output, also has the same effect as specifying the compiler options ‑‑ropi and ‑‑rwpi=got. There is no need for setting these options separately. Shared objects cannot contain code or data on absolute addresses.

Assembler code used in shared objects must also be position-independent, and all code accesses to global data must use the global offset table (GOT)—just like the code generated by the compiler using the option ‑‑rwpi=got.

Note

The options ‑‑rwpi and ‑‑rwpi=sb cannot be used with shared objects.

Dynamic linking

Use of shared objects requires the use of a dynamic linker—or something that can act like a dynamic linker. A dynamic linker can load shared objects into available memory and resolve references to and from them. Dynamic linkers are typically part of an operating system—IAR does not supply a dynamic linker.

The shared objects generated by ILINK adhere to the sequence SVr4 DSO-like PLT Linkage defined in section 7.3 in AAELF32, ELF for the Arm® Architecture 2022Q3. Dynamic linkers that handle such shared objects should be able to handle the shared objects generated by ILINK.

C source code

C++ is not fully supported for shared objects—in particular, central C++ features like vtable (virtual functions), dynamic initialization, and exceptions cannot be used. However, most other C++ constructs will work, so you can use some C++ and still generate a working shared object.

IAR Embedded Workbench for Arm 9.70.x