Changes between Version 4 and Version 5 of Projects/libdl


Ignore:
Timestamp:
Feb 19, 2009, 2:24:30 PM (11 years ago)
Author:
ChrisJohns
Comment:

Fixed source formating and clean up some minor errors.

Legend:

Unmodified
Added
Removed
Modified
  • Projects/libdl

    v4 v5  
    66
    77
    8 Dynamic loading of code into a running RTEMS target has been a long
    9 term wish for many RTEMS users. Dynamic loading is not for all systems
    10 but systems with the resources to support it could make use the
    11 advantages it offers.
     8Dynamic 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.
    129
    13 Dynamic loading means a single binary release of RTEMS can be used by
    14 developers and production release teams. The same binary executable
    15 the application is developed and tested against can be the same binary
    16 executable placed into production. A single check sum can verify the
    17 image. If linking to create a single executable the verification and
    18 validation of the source to library to executable needs to carefully
    19 managed so the application and RTEMS match. A verified and released
    20 RTEMS image can reduce this overhead and therefore provide cost
    21 savings over the life cycle of a project. Dynamic loading allows
    22 developers the ability to load debugging and support code into the
    23 system when running to help locate a problem. This is particularly
    24 useful when a project is in an integration or testing phase and
    25 something has gone wrong.
     10Dynamic 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
     11system 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.
    2612
    27 Dynamic loading for RTEMS does not provide some of the advantages seen
    28 with virtual memory operating system such as Linux. On these systems
    29 dynamic loading allows code to be shared between separate
    30 processes. RTEMS is a single process operating system so there is
    31 nothing to sharing code with. Dynamic loading uses more
    32 resources. Memory is needed by the dynamic linker and space is needed
    33 on the target for the libraries if held locally. You need a working
    34 file system to read the code from into memory, plus there is the
    35 management of symbols. A potential down side of dynamic linking if not
    36 handle efficiently is the possible loading of a complete
    37 library. Virtual memory operating systems such as Linux avoid this
    38 issue by code sharing and demand loading executable files.
     13Dynamic loading for RTEMS does not provide some of the advantages seen with virtual memory operating system such as Linux. 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.
    3914
    40 In recent years Till Straumann has provided a separate package call
    41 cexp to allow loading of modules of code in RTEMS. His excellent
    42 package provides a similar model used in some commercial real-time
    43 operating systems. It how ever does not follow any of the standard
    44 APIs that RTEMS currently follows. It also provides custom solutions
    45 for some of the more complex issues that arise with dynamic loading of
    46 code. This code and his efforts provide an important base for this and
    47 future work related to dynamic loading in RTEMS. An important area he
    48 has solved is the management of targeted linking of libraries such as
    49 libc.
     15In recent years Till Straumann has provided a separate package call cexp to allow loading of modules of code in RTEMS. His excellent package provides a similar model used in some commercial real-time operating systems. It how ever does not follow any of the standard APIs that RTEMS currently follows. Being open source and following standards are two corner stones of RTEMS. The cexp provides custom solutions for some of the more complex issues that arise with dynamic loading of code. This code and his efforts provide an important base for this and future work related to dynamic loading in RTEMS. An important area he has solved is the management of targeted linking of libraries such as libc. How this work translates to the {{{<dlfcn.h></code> API is yet to be determined.
    5016
    51 The IEEE Std 1003.1-2004 standard defines [http://www.opengroup.org/onlinepubs/009695399/functions/dlopen.html  <dlfcn.h>]. This is a
    52 small API that makes an executable object file available to the
    53 calling program. The API calls are:
     17The 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:
    5418
    5519 int    dlclose(void *);
     
    5822 void  *dlsym(void *restrict, const char *restrict);
    5923
    60 The functions provide an interface to the run-time linker and allow
    61 executable object files or shared object files to be loaded into a
    62 process's address space. RTEMS is a single process or single address
    63 space operating system so there is a close mapping to the needs of
    64 RTEMS.
     24The 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.
    6525
    66 Some operating systems provide extra interfaces to help manage
    67 dynamically loaded object files. For example FreeBSD provides
    68 dlinfo. The RTEMS can provide these types of interfaces as
    69 implementation demands.
     26Some 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.
    7027
    7128The central component is the [http://www.freebsd.org/cgi/man.cgi?query=rtld&sektion=1 dynamic linker]. The dynamic linker
    72 provides run-time loading and link-editing of object files. The linker
    73 loads the object file code for all shared libraries into the process's
    74 address space performing any relocation, then proceeds to resolve
    75 external references from both the main program and all object files
    76 loaded. The linker calls initialisation routines for each object file
    77 loaded giving a shared object an opportunity to perform any extra
    78 set-up before execution of the program proper beings. C++ libraries
    79 that contain static constructors require this type of
    80 initialisation. The dynamic linker is specific to the ELF file
    81 format. This means the RTEMS object file format is ELF for targets
    82 that require dynamic loading of object files.
     29provides run-time loading and link-editing of object files. The linker loads the object file code for all shared  libraries into the process's address space performing any relocation, then proceeds to resolve external references from both the main program and all object files loaded. The linker calls initialisation routines for each object file
     30loaded giving a shared object an opportunity to perform any extra set-up before execution of the program proper beings. C++ libraries that contain static constructors require this type of initialisation. The dynamic linker is specific to the ELF file format. This means the RTEMS object file format is ELF for targets that require dynamic loading of object files.
    8331
    84 The main application can be viewed as an object file that is required
    85 to loaded, relocated and initialised before being started. It can be
    86 considered the root of a tree of dynamically referenced object files
    87 loaded at run-time.
     32The main application can be viewed as an object file that is required to loaded, relocated and initialised before being started. It can be considered the root of a tree of dynamically referenced object files loaded at run-time.
    8833= The Task =
    8934
    9035
    91 The task for RTEMS can be split in two, the host side and the target
    92 side. The two sides need to agree on the specific interfaces, formats
    93 and services performed. An example of issues that need to be
    94 considered is libgcc and RTEMS itself. Are these object files also
    95 considered dynamic and loaded by the dynamic linker ?
     36The task for RTEMS can be split in two, the host side and the target side. The two sides need to agree on the specific interfaces, formats and services performed. An example of issues that need to be considered is libgcc and RTEMS itself. Are these object files also considered dynamic and loaded by the dynamic linker ?
    9637
    97 The issue of version numbers for the various components needs
    98 consideration.
     38The issue of version numbers for the various components needs consideration.
    9939
    100 On the host side the aim is to leverage as much existing code as
    101 possible. Dynamic linking is well understand and stable on a number of
    102 operating system using the GNU Compiler Collection. RTEMS also uses
    103 this tool set so the use of dynamic linking features of these tools is
    104 to be investigated and reported. The task starts with attempting to
    105 link a simple application such as "Hello World" dynamically. This will
    106 require the current static RTEMS libraries be made to appear as
    107 dynamic libraries. For an evaluation how this is done is not
    108 important. The static libraries may need to be unpacked as repacked as
    109 dynamic libraries or rebuilt from source. Not all libraries need to
    110 dynamic. One may be enough to report suitable findings.
     40On the host side the aim is to leverage as much existing code as possible. Dynamic linking is well understand and stable on a number of operating system using the GNU Compiler Collection. RTEMS also uses this tool set so the use of dynamic linking features of these tools is to be investigated and reported. The task starts with attempting to link a simple application such as "Hello World" dynamically. This will require the current static RTEMS libraries be made to appear as
     41dynamic libraries. For an evaluation how this is done is not important. The static libraries may need to be unpacked and repacked as dynamic libraries or rebuilt from source. Not all libraries need to be dyna during this phase of the task. One dynamic library may be enough to report suitable findings.
    11142
    112 The target side needs to handle ELF files in an efficient manner. The
    113 license for the code must be compatible with RTEMS. This rules out the
    114 BFD library in the binutils package. It is GPL code and too generic to
    115 meet the specific needs of RTEMS target code. Efficient handling of
    116 symbols is also needed. Compression can be useful here as it provides
    117 for smaller libraries plus it provides a run-time check sum on the
    118 object file or library. Java handles it class libraries this way.
     43The target side needs to handle ELF files in an efficient manner. The license for the code must be compatible with RTEMS. This rules out the BFD library in the binutils package. It is GPL code and too generic to meet the specific needs of RTEMS target code. Efficient handling of symbols is also needed. Compression can be useful here as it provides for smaller libraries plus it provides a run-time check sum on the object file or library. Java handles its class libraries this way.
    11944
    120 A complexity raised earlier that Till handles with a special host side
    121 tool is selective linking against a library. Consider the "Hello
    122 World" example where a call to 'printf' is made. The linking phase
    123 sees the printf symbol is held in the dynamic library libc and fills
    124 the ELF file with the required information to allow the dynamic linker
    125 to perform its task. Our target run-time linker sees the reference to
    126 printf and libc and opens and loads the whole library. It has to do
    127 this because libc has no smaller dynamic library component. Lets now
    128 consider we have a very clever run-time linker that loads only the
    129 object files from libc that are used. That is we dynamically link
    130 everything based on demand at the object file level. The loading and
    131 relocating component can be handled, how-ever the initialisation needs
    132 consideration. How do you handle adding a dlopen call to our example
    133 to load an object file that also references libc but a part that is
    134 not currently loaded and needs loading ? How is this the
    135 initialisation handled ? A possible solution is the breaking down of
    136 libraries into a smaller collection of dynamic libraries. RTEMS could
    137 be packaged this way with a certain effort how-ever libc, libm plus
    138 other libraries also need consideration.
     45A complexity raised earlier that Till handles with a special host side tool is selective linking against a library. Consider the "Hello World" example where a call to 'printf' is made. The linking phase sees the printf symbol is held in the dynamic library libc and fills the ELF file with the required information to allow the dynamic linker to perform its task. Our target run-time linker sees the reference to printf and libc and opens and loads the whole library. It has to do this because libc has no smaller dynamic library component. Lets now consider we have a very clever run-time linker that loads only the object files from libc that are used. That is we dynamically link everything based on demand at the object file level. The loading and relocating component can be handled, how-ever the initialisation needs consideration. How do you handle adding a {{{dlopen</code> call to our example inside {{{main</code> to load an object file that also references libc but a part that is not currently loaded and needs loading ? How is this initialisation handled ? A possible solution is the breaking down of libraries into a smaller collection of dynamic libraries. RTEMS could be packaged this way with a certain effort how-ever libc, libm plus other libraries also need consideration.
    13946= References =
    14047