Interestingly, when I compiled and ran dl01 and dl02 manually, using the source files that were generated during making rtems (like dl-tar.c/h etc.), BUT with application development Makefile (from examples-v2 hello_world_c), AND CFLAGS from the generated Makefile for dl01 test, I got the following output:
*** BEGIN OF TEST libdl (RTL) 1 *** load: /dl-o1.o handle: 0x20409c8 has unresolved externals and the application hanged. Now it seems that there some CFLAGS and/or LDFLAGS or something similar that I missing. Something that happens when testsuites are automatically built, but not when one manually makes them. Any ideas, comments? On Wed, Jul 27, 2016 at 1:00 PM, Saeed Ehteshamifar <salpha.2...@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 <ppisa4li...@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@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: pik...@pikron.com >> ================================================== >> _______________________________________________ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel >> > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
