![[RTEMS Logo]](/images/logo.png){kind=logo}
Dynamic Object File Loading
Status: RTEMS target loader is working and an RTEMS Linker is available. More CPU architectures need to be support.
The project's documentation is generated by doxygen here https://docs.rtems.org/doxygen/branches/master/group__rtems__rtl.html.
Dynamic or run-time loading of code into a running RTEMS system provides a flexible base for systems to control and manage the configuration of complex systems. A common hardware platform can have a kernel created that can support a number of different applications. Application can be created from a number of software components stacked vertically to provide a complete system.
Dynamic loading for RTEMS does not provide the features seen with virtual memory operating system such as Unix. These systems use dynamic loaded code as a way to physically share code between separate processes. RTEMS is a single process operating system so there is no one to share code with. Dynamic loading uses more resources and applications take longer to start because the code needs to be loaded from media and positioned into the address spce. You need a working file system to hold the code to be loaded, plus a symbol table is required to resolve symbols in the base kernel image.
The IEEE Std 1003.1-2004 standard defines <dlfcn.h>. This is a small API that makes an executable object file available to the calling program. The API calls are:
int dlclose(void *); char *dlerror(void); void *dlopen(const char *, int); void *dlsym(void *restrict, const char *restrict);
The functions provide an interface to the run-time linker and allows executable object files or shared object files to be loaded into a process's address space. RTEMS is a single process or single address space operating system so there is a close mapping to the needs of RTEMS.
Some operating systems provide extra interfaces to help manage dynamically loaded object files. For example FreeBSD provides {{{dlinfo</code>. The RTEMS can provide these types of interfaces as implementation demands.
Dynamic loading has been part of the RTEMS kernel since version 4.11.
Architectures supported
| Architecture | Status | Note |
|---|---|---|
| i386 | Implemented | |
| sparc | Implemented | |
| m68k | Implemented | |
| arm | Implemented | |
| powerpc | Implemented | |
| mips | Implemented | |
| nios2 | Implemented | not merged, you can check https://github.com/MrVan/gsoc2013-rtl |
| bfin | Implemented | |
| h8300 | Implemented | |
| lm32 | Implemented | |
| sh | Implemented | not merged, you can check https://github.com/MrVan/gsoc2013-rtl |
| moxie | Implemented | |
| v850 | Implemented | |
| microblaze | Not implemented |
Open Projects
- Implement fixups, veneers or trampolines to reach symbols outside of a relocation record's address space. Compilers often use instructions with a limited number of address bits for offset to jump when executed. Dynamically loaded code can be loaded into an address space that is outside this address space requiring fixups. A fixup is a small piece of code the relocation record branches to before jumping to the symbols address. Some architectures call these veneers or trampolines. The GNU linker inserts these when creating a static image. On a technical level implement this functionality requires an additional pass over the relocation records to determine which relocation records will not reach their target address, the allocation of memory to hold the vectoring code and then the instructions needed to perform the vectoring. An additional complication is the relocation record offset maybe signed so fixup records could be place at either end of the loaded text section if the text section is large.
- Link loading of object files from libraries at runtime. This feature simplifies the system related issues to managing the dependency of object files on common library functions. For example if an object file references a libc or libm symbol that is also referenced in the base kernel image it is resolved when loaded however if it resolves to libc or libm symbol not in the base image it will get an unresolved symbol. The ability to manage this grows in complexity as the amount of code being loaded grows and the dependencies between object files grows in complexity. The solution is to add symbol searching and loading from archives. This can be done rather cheaply by requiring all archives have the symbol table at the start created by the
ranlibtool. The libdl code can hold or cache these symbol tables searching them for a symbol and loading the object file if resolved.
- Support for linker set initialisation tables.
