Versions of ld available

We need the syntax -l:filename in order to support arbitrary file names for shared libraries, at least for RTEMS, see below. I list the Intel linkers here in case someone wants to try, for example, a quick test of new linker script techniques without setting up the cross-compilation environment.

Summary of ld options

If given to a compiler driver instead of directly to ld some of these options need to be prefaced with "-Wl,". However a series of options can be given following a single preface, e.g., "-Wl,-soname=foo,--hash-style=gnu,-zcombreloc".

Option	Needs -Wl,
-shared
-fpic or -fPIC
-e (optional)
-soname
--as-needed
-zcombreloc
--zmax-page-size=4096
--hash-style=gnu
-l: (instead of -l)

File names, sonames and the needed list

A shared library has both a file name and a so-called SO (shared object) name, or soname. The two need not be related as the soname can be set using the ld option -soname. The soname is contained in the dynamic string table at an offset given by the DT_SONAME entry in the dynamic section. Other entries of type DT_NEEDED, which also contain offsets into the dynamic string table, specify the needed list for the shared library. These are the shared libraries that must also be loaded for the shared library to work. Standard convention allows the needed list to contain both file names and sonames but we'll use only sonames.

File name conventions

• SV table objects use the extension ".svt".
• Application, RTEMS, driver and library objects use ".so".

Soname and needed list conventions

1. Every shared object must have a soname.
2. Sonames must be legal C identifiers.
3. Sonames must be no longer than 128 characters long.
4. Needed lists contain no file names, only sonames.
5. The needed list for an shared object must contain an entry for every other shared object it references directly.
6. A shared object must have no undefined references left after linking with ld.
7. The following sonames are reserved:
   1. "RTEMS___" for the shared object containing RTEMS, newlib and other run-time support.
   2. "SYS" for the shared object containing the System Name Table.
   3. "APP" for the shared object containing the Application Name Table.

In general a shared object is found by using Svt_Translate() on the soname in order to obtain the full path name, where the soname is gotten from a needed list. The Symbol-Value tables used by Svt_Translate() are created by compiling C code which is why the sonames must be legal C identifiers. The length restriction on sonames comes from the RTEMS dynamic linker which for efficiency's sake uses a fixed-size buffer to create SVT keys from sonames. Sonames are also the keys used for the database of installed objects.

In order to have a shared object satisfy the requirements listed above we need to use -soname when building every shared object. Then whether you include the object as an input or search for it using -L and -l:, ld will put the soname on the needed list. Referencing an object that lacks an embedded soname will result in the file name of the object being put on the needed list which is not what we want.

All the direct dependencies of the shared object being built should be searched or included as inputs, and undefined references should cause the build to fail (--no-undefined). For efficiency we should use --as-needed which will put only those sonames on the list whose objects actually satisfy references in the object being built; the default is to list every object named as an input or using -l:.

Dynamic symbol table

1. Every shared object must have a GNU-style hash table (--hash-style=gnu). System V hash tables will be ignored.
2. Symbols beginning with "lnk_" are used for data and functions to be made known to the dynamic linker. Currently in use are:
   1. "lnk_preferences" labels object preference data, passed to lnk_prelude().
   2. "lnk_prelude" labels a function to be called by the dynamic linker just after the functions pointed to by the .init_array have been run.

The "lnk_" symbols must have global visibility in order for the dynamic linker to see them. However, it treats them as strictly local definitions and won't make cross-object references with them.

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 statically linked with virtual addresses starting at zero.