Dynamic linking in RTEMS

[Chris Johns]

Pavel, thanks for the excellent detail provided. I will try and expand 
on a couple of parts being discussed.

On 27/07/2016 10:00, Pavel Pisa wrote:
> On Wednesday 27 of July 2016 01:01:29 Saeed Ehteshamifar wrote:
>> 1. How to generate *tar* array? Since on top of dl-tar.c it's been noted
>> that it's automatically generated. If I'm not wrong, by making a tar image,
>> RTEMS puts all binary objects within a single tar file and calls them
>> dynamically at run-time, right?
>
> I am not sure at this moment, how it is done by mainline samples makefiles
> but simplified command sequence from my examples follows.
>

The rtems_waf support (https://git.rtems.org/chrisj/rtems_waf.git/) now 
provides a simple way to add files via an embedded tar file to an 
executable. You can:

   rtems.root_filesystem(bld, 'rootfs',
                         ['etc/rc.conf',
                          'x',
                          'y',
                          'z'],
                         'rootfs.tar', 'rootfs-tar.o')

Just add 'rootfs-tar.o' to list of source to link. Add code to your 
application to untar the files:

  extern int _binary_rootfs_tar_start;
  extern int _binary_rootfs_tar_size;

  static void
  expand_rootfs_tarfile(void)
  {
    rtems_status_code sc;
    rtems_printer     printer;
    rtems_print_printer_printf(&printer);
    sc = Untar_FromMemory_Print((void *)(&_binary_rootfs_tar_start),
                                (size_t)&_binary_rootfs_tar_size,
                                &printer);
    if (sc != RTEMS_SUCCESSFUL)
      fprintf(stderr, "error: untar failed: %s\n",
              rtems_status_text(sc));
  }

>> 2. What's the difference between dl01.exe and dl01.pre? Both are executable
>> but running dl01.pre leads to "unresolved externals" and the execution
>> hangs.
>
> You need to link list of symbols to the base executable image
> to inform runtime linker which symbols are available.

There are two ways you can manage symbols and it depends on your system 
architecture and available services in your running target.

You can embed the symbols in the base image. To do this you need two 
link passes. The first link pass brings the executable together so you 
can get a list of symbols. This is used to create a symbol table you add 
to the second link pass. The way the symbol table is created and linked 
allows it to adjust to a different memory map created by the second link 
pass.

The second method is loading an external symbol table. This is a single 
link process and again you create a symbols object file which is 
external. Instead of a 2nd phase of linking you simply make the symbol's 
object file available to the running target and you dynamically load it 
before any other modules. In this case the symbol addresses are fixed to 
the addresses in the executable.

An example of an embedded symbol table is a target that does not have a 
flash file system or a network to load external symbols. It is also used 
when you do not want to have to configuration control the kernel image 
and the symbols. The two link passes added complexity to your build system.

An example of external symbols is a team development environment where a 
boot loader such as iPXE or uboot loads a kernel from the network and 
you load the symbols via the network as well. When you move to a 
production build the symbols are loaded into a local file system.

Chris