Dynamic linking in RTEMS

Wed Jul 27 13:21:07 UTC 2016

>
> 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:
>
> How can I start using WAF build system? I found
> https://devel.rtems.org/wiki/waf on the wiki but it wasn't helping much.
>
Found it at
https://ftp.rtems.org/pub/rtems/people/chrisj/rtl/rtems-linker/waf.html.

On Wed, Jul 27, 2016 at 1:00 PM, Saeed Ehteshamifar <salpha.2004 at gmail.com>
wrote:

> Hello,
>
> Thanks for the answers Pavel, Chris.
>
> You need to link list of symbols to the base executable image
>> to inform runtime linker which symbols are available.
>
> I followed your instructions carefully and after building my app, I get an
> "untar failed: 1" error. How should I debug this error? My application is
> attached to the email I would really appreciate if you can have a look.
> I was thinking to put this app on examples-v2 to serve as a starting point
> for DL app dev. Though I don't know if the DL lib usage is stable now.
>
> 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:
>
> How can I start using WAF build system? I found
> https://devel.rtems.org/wiki/waf on the wiki but it wasn't helping much.
>
> There are two ways you can manage symbols and it depends on your system
>> architecture and available services in your running target.
>
> I was wondering why I couldn't find "rtems_main" symbol in
> libtests/dl01.exe:
> sparc-rtems4.12-nm $(find . -name dl01.exe) | grep "rtems_main"
>
> Shouldn't the exe version contain all the symbols required for the dynamic
> linker?
>
> Best Regards,
> Saeed
>
> On Wed, Jul 27, 2016 at 11:28 AM, Pavel Pisa <ppisa4lists at pikron.com>
> wrote:
>
>> 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
>> ==================================================
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20160727/ae4d9722/attachment-0002.html>