Dynamic linking in RTEMS

[Pavel Pisa]

Hello Chris,

thanks for clarification.

On Wednesday 27 of July 2016 02:57:06 Chris Johns wrote:
> Pavel, thanks for the excellent detail provided. I will try and expand
> on a couple of parts being discussed.
> > 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.

In the fact, I would like to have third supported/maintained way
for the table inclusion in the base RTEMS application image.

It would be great if it is possible to select "API profiles"
which should be exported to the loadable code.
These profiles should be (ideally) maintained directly
in RTEMS mainline. My idea is that I decide that I need
POSIX, RTEMS and dynamic loader API exported, so I put in Init
of base application

  rtems_rtl_base_register_sym_table(&rtems_rtl_base_sym_table_posix);
  rtems_rtl_base_register_sym_table(&rtems_rtl_base_sym_table_rtems);
  rtems_rtl_base_register_sym_table(&rtems_rtl_base_sym_table_libdl);

The main problem with this approach is to found intermediatte
symbols required by these directives which are implemented by
inlines or macros (that is, documented externally visible name
does not correspond directly to the symbol).

It would be ideal, if officially exported, documented API function
are somehow marked (Doxygen?) that these official tables can
be build automatically.

From the long term perspective for RAM memory constrained systems,
it would be ideal, if symbol table can be recompiled to the format
which can be stored directly into Flash/RO memory and does not need
memory dynamic allocation as is used now

  obj->global_size = count * sizeof (rtems_rtl_obj_sym_t);
  obj->global_table = rtems_rtl_alloc_new (RTEMS_RTL_ALLOC_SYMBOL,

But keeping the same format for that embedded symbol tables
and dynamically loaded ones which require updates can be challenge.

Best wishes,

              Pavel

> 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
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

-- 
Yours sincerely
                Pavel Pisa

==================================================
 PiKRON s.r.o.       Phone/Fax: +420 284684676
 Kankovskeho 1235    Phone:     +420 234697622
 182 00 Praha 8      WWW:   http://www.pikron.com/
 Czech Republic      e-mail:  pikron at pikron.com
==================================================