Dynamic linking in RTEMS

[Chris Johns]

On 27/07/2016 19:28, Pavel Pisa wrote:
> 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 other way to handle this, and my preferred option, is to add 
filtering to 'rtems-syms'. The user could select a range of standard 
profiles or the user could provided their own profile. This provides 
flexibility at the system level because user code in the base image can 
be managed in a similar way to the kernel symbols. Users deploying 
products can expand the base kernel profiles to include custom 
interfaces. It would also make the resulting overheads smaller because 
it is still a single base symbol table. Adding const tables as you 
suggested would require a RAM based list of some form.

The filter definitions should be simple because it is working at the 
symbol table level and the symbols are just strings. The ABI 
compatibility is handled at a different level by the user and in RTEMS 
we do not concern ourselves with binary compatibility or the overheads 
that involves because we have all the source and build all that source 
with the same tool chain and the same options. Runtime ABI compatibility 
make no sense in an embedded real-time system.

> 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).

You need to use the header files to build the loadable code so I would 
have thought the inlines, macros etc would be handled locally by the 
compiler when building the loadable code? I agree how you document this 
in relationship to a resulting symbol in the symbol table is an 
interesting problem.

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

Documenting in doxygen is a good idea. I feel automatically creating the 
list means things can sneak into the interface without review. I would 
hope the list of symbols in these tables is small and can be managed 
manually. At this point in time I prefer a manual approach. If symbol 
filtering is used the profile definition will be manual to start with 
anyway.

If ELF notes can be added via some form of compiler attribute we can 
then check the filters are valid. I do not know if this is possible or 
how you do this. Tagging the function decl is attractive.

>  From the long term perspective for RAM memory constrained systems,
> it would be ideal,

A lot of effort was put into keeping the amount of memory allocated and 
the number of allocations small so it is encouraging and really good to 
see libdl being considered for RAM constrained systems.

> 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

This is possible.

>    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.

This is a great idea and can be done. I am not sure how much effort is 
required.

Chris