Table of Contents

Types of shared

...

object

In our refactoring of RTEMS we've created several different types of shared objects. All are ELF dynamic objects in overall structure but each plays a different role:

• RTEMS object (rtems.so). This contains most of RTEMS, newlib and other basic runtime support. It's unique in that it's not loaded by the dynamic linker; instead it's loaded by U-Boot at a fixed location, the start of the Run-Time Support Region of memory. U-Boot loads each segment of rtems.so at  the so-called physical address of the segment so we have to use a special linker script to set those properly. The RTEMS object is permanently resident, aka a.k.a. installed.
• Symbol-Value Tables (*.svt).The dynamic symbol table of this type of object is used as a read-only lookup table whose content is defined by C source code. Each symbol's value is the location of a data object, generally a string or a struct. There can be up to 32 SVTs numbered 0-31, with number 31, the System table sys.svt, and number 30, the Application table app.svt, being loaded at system startup.
• Ordinary shared objects, aka a.k.a. shareables (*.so). Basically add-on libraries that are installed when needed, e.g., nfs.so and console.so.
• Tasks (*.exe). A task is roughly equivalent to a main program. The loader and dynamic linker cooperate to load a task and, when necessary, to load and install any shareables it needs. A task also has an associated thread which executes the task code starting at its entry point, always present and always named askTask_Entry(). The properties of the task such as name, priority, etc., are usually looked up in an SVT. One or more tasks are automatically chosen, using more information stored in SVTs, to be loaded and run at system startup. Note that tasks are never themselves installed.
• Device drivers (*.drv). These objects perform device initialization and may register RTEMS device drivers. They are always installed.

All types of objects except rtems.so:

• Are loaded into storage that is allocated dynamically from the RTS Region.
• May have a function called lnk_prelude() which is called after the object is fully linked and initialized but before the entry point, if any, is called. For instance driver objects have no entry point but do their work in their lnk_prelude() functions.
• May contain a 32-bit word named lnk_options which is a bit-mask of dynamic linker options defined in tool/elf/linker.h:
  • LNK_INSTALL. Install this shared object.
  • LNK_USE_PREFERENCES. Find a preferences structure for the object and pass its address to lnk_prelude().

The lnk_prelude() function

Consider this the last stage of the construction of the object's image in memory. The image should not be considered complete before this function is run, so it's a programming error to have the image used by other images before lnk_prelude() has finished running.

lnk_prelude() takes two arguments and returns a standard facility/error code. The arguments are two void-pointers:

1. prefs. Either NULL or the address of a preferences structure for the image. The function must cast the pointer to the type that's correct for the image.
2. elfAddr. The address of the ELF file header.

Loadable segments

A shared object may have any number of loadable segments. One of them must contain the ELF file header and the program headers. Since the file header starts at the offset zero in the file then the segment that contains it will also have an file offset of zero and will usually have the lowest address as well. After loading the access permissions of the memory containing a segment are changed to match the permissions recorded in the segment. Permissions can change only at 4K boundaries in the RTS region so segments must be aligned tho 4K boundaries. We recommend the following set of segments:

1. Read-only data containing the file header and the program header table.
2. Executable, read-only text.
3. Read-write data.

Versions of ld available

...

The ARM cross-compilers use .init_array to hold pointers to compiler-generated functions that run constructors for statically allocated C++ objects. Therefore .init_array is processed before calling lnk_prelude(). However, lnk_prelude() can't itself be called using the .init_array mechanism because it takes arguments, it returns a status value and there's no way to control the ordering of entries in .init_array.

RTEMS shared object

The shared object containing RTEMS, newlib and other run-time support is unique in that it has to be loaded at a fixed location, the start of the RTS Region. The loading is done by U-Boot which looks at the physical addresses of the loadable segments in order to determine where to put them. In order to set the physical addresses properly the linker script for the RTEMS object assigns all output to a region of memory, defined using the MEMORY directive, whose origin is at the required location. This has the side effect of giving the lowest loadable segment in the shared object a non-zero starting virtual address which has to be taken into account when using symbols defined by the object. All other shared objects are created with virtual addresses starting at zero.