= Dynamic Object File Loading = [[TOC(Projects/libdl, depth=2)]] '''Status:''' RTEMS target loader is working and an RTEMS Linker is available. More CPU architectures need to be support. The project's documentation is generated by doxygen. You can view a current version here: http://www.rtems.org/ftp/pub/rtems/people/chrisj/rtl/rtems-linker/ Dynamic loading of code into a running RTEMS target has been a long term wish for many RTEMS users. Dynamic loading is not for all systems but systems with the resources to support it could make use of the advantages it offers. Dynamic loading means a single binary release of RTEMS can be used by developers and production release teams. The same RTEMS binary executable the application is developed and tested against can be the same binary executable placed into production. A single check sum can verify the images match. If statically linking to create a single executable the verification and validation of the source to library to executable needs be carefully managed so the application and RTEMS match. A verified and released RTEMS image can reduce this overhead and therefore provide cost savings over the life cycle of a project. Dynamic loading allows developers the ability to load debugging and support code into the system when running to help locate a problem. This is particularly useful when a project is in an integration or testing phase and something has gone wrong. Dynamic loading for RTEMS does not provide some of the advantages seen with virtual memory operating system such as Unix. On these systems dynamic loading allows code to be shared between separate processes. RTEMS is a single process operating system so there is nothing to share code with. Dynamic loading uses more resources and takes longer to start the application. Memory is needed by the dynamic linker and space is needed on the target for the libraries if held locally. You need a working file system to read the code into memory, plus there is the management of symbols. A potential down side of dynamic linking if not handle efficiently is the possible loading of a complete library. Virtual memory operating systems such as Linux avoid this issue by code sharing and demand loading executable files. The IEEE Std 1003.1-2004 standard defines [http://www.opengroup.org/onlinepubs/009695399/functions/dlopen.html ]. This is a small API that makes an executable object file available to the calling program. The API calls are: {{{ int dlclose(void *); char *dlerror(void); void *dlopen(const char *, int); void *dlsym(void *restrict, const char *restrict); }}} The functions provide an interface to the run-time linker and allows executable object files or shared object files to be loaded into a process's address space. RTEMS is a single process or single address space operating system so there is a close mapping to the needs of RTEMS. Some operating systems provide extra interfaces to help manage dynamically loaded object files. For example FreeBSD provides {{{dlinfo. The RTEMS can provide these types of interfaces as implementation demands. = Acknowledgements = * Till Straumann implement the CEXP package which included dynamic loading. * JiSheng Zhang ported the dynamic loader from Android Bison LIBC to RTEMS as part of Google Summer of Code 2009. * Alan Cudmore mentored JiSheng Zhang. = The Task = The current status is two separate git repos exist: http://git.rtems.org/chrisj/rtl.git/ http://git.rtems.org/chrisj/rtl-host.git/ These are both waf based projects. The RTL Host project builds the RTEMS Linker (rtems-ld) and the RTL project builds an RTEMS application that runs on the i386 and SPARC processors. The RTL project uses a version of libsbports I am yet to make public (no time) where libbspport is a dynamic module loaded at runtime. It runs on a real PC, loads and detects a PCI based network card. This is a sizeable application with over 14,000 relocation fix ups. The RTEMS Linker support the RTEMS Application Format (RAP) file format. This is a compressed post link processed file. = Open Projects = The RTEMS port supports i386 and SPARC. We need more architectures. Updating the source and remerging our extra targets will resolve some of these. Developing more test cases. Functional level unit testing of the RTEMS Linker. This is a complex C++ application and the RAP processing is complex and contains bugs. Architectures supported: {| border="1" style="margin: 1em auto 1em auto;text-align: center;" |+ |- |'''Architecture''' || '''Supported''' || '''Source reference''' || ''' Verified ''' || ''' Relocation Types support ''' |- |i386 || Yes || NetBSD || Yes || Partial |- |sparc || Yes || NetBSD || Yes || Partial |- |m68k || Yes || NetBSD || Yes || Partial |- |arm || Yes || NetBSD || No || Partial |- |powerpc || Yes || NetBSD || No || Partial |- |mips || No |- |nios2 || No |- |bfin || No |- |h8300 || No |- |lm32 || No |- |sh || No |- |moxie || No |- |lm32 || No |- |v850 || No |- |microblaze || No |- |avr || No |- |m32r || No |- |m32c || No |- |}= References = # FreeBSD Man Pages - dlopen: http://www.freebsd.org/cgi/man.cgi?query=dlopen&format=html # Open Group Single Unix Specification: http://www.opengroup.org/onlinepubs/009695399/functions/dlopen.html # FreeBSD Man Pages - ld-elf.so.1, ld.so, rtld: http://www.freebsd.org/cgi/man.cgi?query=rtld&sektion=1