Page History

Overview

The DAT RPT group has divided RTEMS and DAT RPT support code into a number of "dynamically shared objects" which are structurally the same as the shared libraries one uses under Linux [ELF]

Anchor
refELF refELF

. There are two kinds of linking, or binding pieces of compiled code into a single functioning whole. The first kind of linking, static linking, creates the shared objects from the ".o" files produced by the compiler. The second kind of linking, dynamic linking, loads shared objects into memory on demand while the program is already running. As the name implies a single copy of a shared object's code and data may be used by a number of other shared objects which reduces the use of memory. There is also a potential reduction gained from loading only those shared objects that contain what's actually needed.

The system boot loader loads and starts the principle shared object containing RTEMS and the DAT RPT dynamic linker. Then the application initialization code written by the DAT RPT group uses the dynamic linker to load the remaining shared objects specified by the system configuration, itself contained in several shared objects.

...

• The shared object whose name you give as an argument is never installedloaded but not "installed" (see below).
• If that shared object depends upon others then such of those others that are not already loaded are loaded.
• Shared objects that are loaded as dependencies are installed if they request it and if they are not already installed.
• A shared object isn't allowed to list itself as a dependency.

...

Notice that the soname "system:rtems.so" has two components separated by a colon. The first component, "system" give gives the namespace to which the shared object belongs. Objects in the same namespace are found in the same place. Where that place is is determined by the system's namespace table; each namespace name is associated with a directory in the RTEMS filesystem. The second component of the soname, "rtems.so" is the filename of the shared object after all directories have been removed. If the system namespace table associates "/mnt/rtems" with the namespace "system" then "system:rtems.so" will be looked for at /mnt/rtems/rtems.so when the time comes to load it.

...

Though each shared object contains a list of the sonames of all the other shared objects it depends on, the so-called needed-list, this doesn't tell the dynamic linker just what the object requires from the other objects. It could be user data, functions, classes, etc. Each of these items has a symbolic a  name which appears in a symbol table built into the shared object that defines them. The object that needs to use them also has the symbolic the  names in its table, though marked as "undefined", that is to say "not defined in this shared object". There's no indication of which shared object is the definer. Instead, for each undefined symbol in a newly-loaded object the dynamic linker searches for a definition in each of the objects on the first object's needed-list [scope]

Anchor
#refScope #refScope

, taking the first definition that it finds. It doesn't check for duplication. The linker then puts the address of the definition it found into all the places in the first shared object that require it.

...

Shared objects to be run on a DAT RPT system may have two optional initialization functions which if present are called by the dynamic linker. The first, lnk_preferences() , returns a 32-bit preference datum which may be an int or a pointer and is passed as an argument to lnk_prelude(). The latter function is a general initialization function designed to be more easily used than the .init section. Since most other initialization for the shared object has been done, lnk_prelude() can do most anything: start tasks, load other shared objects, print messages, etc.

...

A shared object file's loadable content is divided into a small number of "segments". Each segment has a set of permission flags: (R)eadable, (W)riteable ans and e(X)ecutable. In shared objects built for DAT RPT systems there's normally one RX segment containing instructions and read-only data and one RW section containing non-constant data. The dynamic linker uses the CPU's memory management unit (MMU) to set the access type of the memory allocated to each segment to match the segment's permission flags.

...

Anchor
noteELF noteELF

[ELF] The file format used is the standard Executable and Linkable Format. The ELF standard defines three kinds of objects: compiler output (not directly executable), executable main programs and executable dynamic shared objects. DAT RPT systems allow the loading and execution only of files in the third format.

Anchor
noteScope noteScope

[scope] For any given shared object the set of objects searched to satisfy its undefined references is called its scope. For DAT RPT code the scope is the original shared object followed by the objects named in its needed-list. It may seem strange to search an object for its own undefined symbols but it's necessary to handle some unusual cases. This scope rule is much simpler than the one employed by a Linux dynamic linker.

...