Dynamic linking in RTEMS

Wed Jul 27 11:00:02 UTC 2016

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/c66be91b/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: build.sh
Type: application/x-sh
Size: 873 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20160727/c66be91b/attachment-0002.sh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hello.c
Type: text/x-csrc
Size: 177 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20160727/c66be91b/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: init.c
Type: text/x-csrc
Size: 1453 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20160727/c66be91b/attachment-0005.bin>