Changes between Version 20 and Version 21 of Projects/libdl

Timestamp:

11/29/18 23:18:36 (6 years ago)

Author:

Chris Johns

Comment:

Update the status.

Projects/libdl

@@ -1 +1 @@
 = Dynamic Object File Loading =
 
-
-
-[[TOC(Projects/libdl, depth=2)]]
-
+[[TOC(Projects/libdl, depth=4)]]
 
 '''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:
+The project's documentation is generated by doxygen here https://docs.rtems.org/doxygen/branches/master/group__rtems__rtl.html.
 
-http://www.rtems.org/ftp/pub/rtems/people/chrisj/rtl/rtems-linker/
+Dynamic or run-time loading of code into a running RTEMS system provides a flexible base for systems to control and manage the configuration of complex systems. A common hardware platform can have a kernel created that can support a number of different applications. Application can be created from a number of software components stacked vertically to provide a complete system.
 
-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.
+Dynamic loading for RTEMS does not provide the features seen with virtual memory operating system such as Unix. These systems use dynamic loaded code as a way to physically share code between separate processes. RTEMS is a single process operating system so there is no one to share code with. Dynamic loading uses more resources and applications take longer to start because the code needs to be loaded from media and positioned into the address spce. You need a working file system to hold the code to be loaded, plus a symbol table is required to resolve symbols in the base kernel image.
 
 The IEEE Std 1003.1-2004 standard defines [http://www.opengroup.org/onlinepubs/009695399/functions/dlopen.html  <dlfcn.h>]. This is a small API that makes an executable object file available to the calling program. The API calls are:
@@ -31 +23 @@
 
 Some operating systems provide extra interfaces to help manage dynamically loaded object files. For example FreeBSD provides {{{dlinfo</code>. 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.
+Dynamic loading has been part of the RTEMS kernel since version 4.11.
 
 = Architectures supported =
@@ -76 +43 @@
 || v850 || Implemented || 
 || microblaze || Not implemented || 
-|| avr || Not implemented || 
-|| m32r || Implemented ||
-|| m32c || Not implemented ||
+
+= Open Projects =
+
+1. Implement fixups, veneers or trampolines to reach symbols outside of a relocation record's address space. Compilers often use instructions with a limited number of address bits for offset to jump when executed. Dynamically loaded code can be loaded into an address space that is outside this address space requiring fixups. A fixup is a small piece of code the relocation record branches to before jumping to the symbols address. Some architectures call these veneers or trampolines. The GNU linker inserts these when creating a static image. On a technical level implement this functionality requires an additional pass over the relocation records to determine which relocation records will not reach their target address, the allocation of memory to hold the vectoring code and then the instructions needed to perform the vectoring. An additional complication is the relocation record offset maybe signed so fixup records could be place at either end of the loaded text section if the text section is large.
+
+2. Link loading of object files from libraries at runtime. This feature simplifies the system related issues to managing the dependency of object files on common library functions. For example if an object file references a libc or libm symbol that is also referenced in the base kernel image it is resolved when loaded however if it resolves to libc or libm symbol not in the base image it will get an unresolved symbol. The ability to manage this grows in complexity as the amount of code being loaded grows and the dependencies between object files grows in complexity. The solution is to add symbol searching and loading from archives. This can be done rather cheaply by requiring all archives have the symbol table at the start created by the `ranlib` tool. The libdl code can hold or cache these symbol tables searching them for a symbol and loading the object file if resolved.
+
+3. Support for linker set initialisation tables.
 
 = References =