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