The RTEMS Linker and RTEMS Target Link Editor provides RTEMS with the ability to support applications loaded and linked at runtime. RTEMS is a single address space real-time operating system designed for embedded systems that are statically linked therefore the idea of applications requires some extra understanding when applied to RTEMS. They are not essential, rather they are important in a range of systems that have the resources available to support them.

Applications allow:

A team to create a single verified base kernel image that is used by all team developers. This kernel could be embedded on the target hardware and applications loaded over a network. The verified kernel binary used during development can be shipped without being changed.

Layered applications designed as modules that are loaded at runtime to create a specific target environment for a specific system. This approach allows development of modules that become verified components. An example is the NASA Core Flight Executive.

Runtime configuration and loading of features or drivers based on configuration data or detected hardware. This is important if your target hardware has an external bus such as PCI. You can add a new driver to a system without needing to rebuild the kernel and application lowering the verify and validation costs. If these are high the savings can be substantial.

RTEMS is a single address space operating system therefore any code loaded is loaded into that address space. This means applications are not operating in a separate protected address space you typically get with host type operating systems. You need to control and manage what you allow to load on your system. This is no differerent to how single image RTEMS are currently created and managed. The point being RTEMS applications only changes the way you package and maintain your applications and do not provide any improved security or protection. You need to do this as your currently do with testing and careful design.

RTEMS is statically linked to a fixed address and does not support dynamic ELF files. Dynamic ELF files are designed for use in virtual memory protected address space operating systems. They contain Position Independent Code (PIC) code, Procedure Linkage Tables (PLT) and Global Offset Tables (GOT) and are effective in not only allowing dynamic linking at runtime but also the sharing of the code between separate process address spaces. Using virtual memory and a memory management unit, a protected address space operating system can efficiently share code between processes with minimal performance overhead. RTEMS has no such need because it is a single address space and all code is shared therefore ELF dynamic files only add complexity and performance overhead. This means RTEMS needs a target based run-time link editor that can relocate and fix up static code when loading it and RTEMS loadable files need to contain the symbols and relocation records to allow relocation to happen.

The RTEMS Target Link Editor supports the followiing file formats:

Relocatable ELF (ELF)
RTEMS Application (RAP)
Archive (AR) Libraries with GNU extensions

Relocation ELF Files

The RTEMS Target Link Editor can load standard relocatable ELF format files. They can be stripped or unstripped. This ELF file is the standard output from the compiler and is contained in the standard libraries.

RTEMS Application (RAP) Files.

The RTEMS Target Link Editor can load RAP format files. This format is RTEMS specific and is designed to minimise the overhead and resources needed to load the file on the target. A RAP file is compressed using LZ77 compression and contains only the following sections:

.text - The executable code section.
.const - The constants and strings section.
.ctor - The constructor table section.
.dtor - The destructor table section.
.data - The initialised data section.

The .bss uninitialised data section is only a size. A RAP file also contains a symbol string table and symbol table that are directly loadable into into the target memory. Finally the RAP contains the relocation records. The format is structured so it can be read and processed as a stream with the need to seek on the file.

The RTEMS Linker can output RAP format files suitable for loading. It will take the object files from the command line and the referenced files from the libraries and merge all the sections, symbols and relocation records to create the RAP format file.

RAP format files are the most efficient way to load applications or modules because all object files are merged into an single image. Each file loaded on the target has and overhead therefore lowering the number of files loaded lowers the overhead. You could also use the standard linker to incrementally link the command line object files to archieve the same effect.

Archive (AR) Library Files

The RTEMS Target Link Editor can load from archive ior library type files. The file name syntax lets a user reference a file in an archive. The format is:

: libme.a:foo.o@12345

where libme.a is the archive file name, foo.o is the file in the archive and @12345 is optionally the offset in the archive where the file starts. The optional offset helps speed up load by avoiding the file name table search. If the archive is stable and known the offset will be fixed. If the file is located at the offset the file name table is searched.

At this point in time only ELF files can be loaded from archives. Loading of RAP format files is planned.

An Application

Applications are created the same way you create standard host type programs. You compile the source files and link them using the RTEMS Linker.

$ rtems-ld --base my-rtems foo.o bar.o -o my-app.rap -L /lib/path -lstuff

The command line of the RTEMS Linker is similar to a standard linker with some extra features specific to RTEMS. You provide a list of object files, libraries and library paths plus you need to provide the RTEMS kernel image you will use to load the application. The RTEMS kernel image provides the symbols in the kernel to the linker. Errors will be generated if symbols are not located.

The linker can output a archive of ELF files, a RAP file for a text script of files that need to be loaded.

The script lets you load and link the application at runtime on the target. You need to copy the libraries referenced to the target.

If you break your application into separate modules and each module references a symbol in a library that is not in the base image the linker will include the object file containing the symbol into each application module. This is only of concern for the RAP format because it merges the object files together. With the archive and scripts the loader will not load object files with duplicate symbols.

Note: In time the linker will gain an option to not pull object modules from libraries into the RAP file. Another option will be added that will copy referenced library object files into a target library all application modules can share.

Linking

The RTEMS Linker places the command line object files in the output image and any reference object files found in libraries. If a symbol is located in the kernel base image it is not searched for in the libraries.

The architecture is automatically detected by inspecting the first object file passed on the command line. All future object files loaded must match the architecture for an error is raised. The linker supports all architectures in a single binrary. It is not like the GNU tools which are specific to an architecture.

The linker needs to be able to locate the C compiler for the architecture being linked. The compiler can be in the path for a command line option can explicitly set the compiler. The compiler is used to locate the standard libraries such as the C library.