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 >
build.sh
Description: Bourne shell script
#include <stdio.h>
#include <stdlib.h>
int hello ()
{
printf("\n\n*** HELLO WORLD ***\n");
printf("Hello World\n");
printf("*** END OF HELLO WORLD ***\n");
return 0;
}
#include <rtems.h>
#include <stdlib.h>
#include <stdio.h>
#include <sys/types.h>
#include <dlfcn.h>
#include <rtems/rtl/rtl.h>
#include <rtems/untar.h>
extern int _binary_dl_tarfile_start;
extern int _binary_dl_tarfile_size;
rtems_task Init(
rtems_task_argument ignored
)
{
int (*hello)();
int te = Untar_FromMemory((void *)(&_binary_dl_tarfile_start),
(size_t)(&_binary_dl_tarfile_size));
if (te != 0)
{
printf("untar failed: %d\n", te);
exit (1);
}
void* handle = dlopen ("/hello.o", RTLD_NOW | RTLD_GLOBAL);
if (!handle)
{
printf("dlopen failed: %s\n", dlerror());
exit(1);
}
printf ("handle: %p \n", handle);
hello = dlsym (handle, "hello");
if (hello == NULL)
{
printf("dlsym failed: symbol not found\n");
exit(1);
}
(*hello)();
if (dlclose (handle) < 0)
{
printf("dlclose failed: %s\n", dlerror());
exit(1);
}
printf ("handle: %p closed\n", handle);
exit(0);
}
/* configuration information */
#include <bsp.h>
#define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS 4
#define CONFIGURE_MAXIMUM_TASKS 1
#define CONFIGURE_MINIMUM_TASK_STACK_SIZE (8U * 1024U)
#define CONFIGURE_EXTRA_TASK_STACKS (8 * 1024)
#define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
#define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
#define CONFIGURE_INITIAL_EXTENSIONS RTEMS_TEST_INITIAL_EXTENSION
#define CONFIGURE_RTEMS_INIT_TASKS_TABLE
#define CONFIGURE_INIT
#include <rtems/confdefs.h>
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
