Changes between Version 2 and Version 3 of Projects/libdl


Ignore:
Timestamp:
02/19/09 09:01:11 (15 years ago)
Author:
ChrisJohns
Comment:

Add TOC and fix The Task heading.

Legend:

Unmodified
Added
Removed
Modified
  • Projects/libdl

    v2 v3  
    11= Dynamic Object File Loading =
     2
     3
     4
     5[[TOC(Projects/libdl, depth=2)]]
    26
    37
     
    8286considered the root of a tree of dynamically referenced object files
    8387loaded at run-time.
    84 =  =ynamic loading of code into a running RTEMS target has been a long
    85 term wish for many RTEMS users. Dynamic loading is not for all systems
    86 but systems with the resources to support it could make use the
    87 advantages it offers.
     88= The Task =
    8889
    89 Dynamic loading means a single binary release of RTEMS can be used by
    90 developers and production release teams. The same binary executable
    91 the application is developed and tested against can be the same binary
    92 executable placed into production. A single check sum can verify the
    93 image. If linking to create a single executable the verification and
    94 validation of the source to library to executable needs to carefully
    95 managed so the application and RTEMS match. A verified and released
    96 RTEMS image can reduce this overhead and therefore provide cost
    97 savings over the life cycle of a project. Dynamic loading allows
    98 developers the ability to load debugging and support code into the
    99 system when running to help locate a problem. This is particularly
    100 useful when a project is in an integration or testing phase and
    101 something has gone wrong.
    102 
    103 Dynamic loading for RTEMS does not provide some of the advantages seen
    104 with virtual memory operating system such as Linux. On these systems
    105 dynamic loading allows code to be shared between separate
    106 processes. RTEMS is a single process operating system so there is
    107 nothing to sharing code with. Dynamic loading uses more
    108 resources. Memory is needed by the dynamic linker and space is needed
    109 on the target for the libraries if held locally. You need a working
    110 file system to read the code from into memory, plus there is the
    111 management of symbols. A potential down side of dynamic linking if not
    112 handle efficiently is the possible loading of a complete
    113 library. Virtual memory operating systems such as Linux avoid this
    114 issue by code sharing and demand loading executable files.
    115 
    116 In recent years Till Straumann has provided a separate package call
    117 cexp to allow loading of modules of code in RTEMS. His excellent
    118 package provides a similar model used in some commercial real-time
    119 operating systems. It how ever does not follow any of the standard
    120 APIs that RTEMS currently follows. It also provides custom solutions
    121 for some of the more complex issues that arise with dynamic loading of
    122 code. This code and his efforts provide an important base for this and
    123 future work related to dynamic loading in RTEMS. An important area he
    124 has solved is the management of targeted linking of libraries such as
    125 libc.
    126 
    127 The IEEE Std 1003.1-2004 standard defines [http://www.opengroup.org/onlinepubs/009695399/functions/dlopen.html  <dlfcn.h>]. This is a
    128 small API that makes an executable object file available to the
    129 calling program. The API calls are:
    130 
    131  int    dlclose(void *);
    132  char  *dlerror(void);
    133  void  *dlopen(const char *, int);
    134  void  *dlsym(void *restrict, const char *restrict);
    135 
    136 The functions provide an interface to the run-time linker and allow
    137 executable object files or shared object files to be loaded into a
    138 process's address space. RTEMS is a single process or single address
    139 space operating system so there is a close mapping to the needs of
    140 RTEMS.
    141 
    142 Some operating systems provide extra interfaces to help manage
    143 dynamically loaded object files. For example FreeBSD provides
    144 dlinfo. The RTEMS can provide these types of interfaces as
    145 implementation demands.
    146 
    147 The central component is the [http://www.freebsd.org/cgi/man.cgi?query=rtld&sektion=1 dynamic linker]. The dynamic linker
    148 provides run-time loading and link-editing of object files. The linker
    149 loads the object file code for all shared libraries into the process's
    150 address space performing any relocation, then proceeds to resolve
    151 external references from both the main program and all object files
    152 loaded. The linker calls initialisation routines for each object file
    153 loaded giving a shared object an opportunity to perform any extra
    154 set-up before execution of the program proper beings. C++ libraries
    155 that contain static constructors require this type of
    156 initialisation. The dynamic linker is specific to the ELF file
    157 format. This means the RTEMS object file format is ELF for targets
    158 that require dynamic loading of object files.
    159 
    160 The main application can be viewed as an object file that is required
    161 to loaded, relocated and initialised before being started. It can be
    162 considered the root of a tree of dynamically referenced object files
    163 loaded at run-time.
    164 =  =ynamic loading of code into a running RTEMS target has been a long
    165 term wish for many RTEMS users. Dynamic loading is not for all systems
    166 but systems with the resources to support it could make use the
    167 advantages it offers.
    168 
    169 Dynamic loading means a single binary release of RTEMS can be used by
    170 developers and production release teams. The same binary executable
    171 the application is developed and tested against can be the same binary
    172 executable placed into production. A single check sum can verify the
    173 image. If linking to create a single executable the verification and
    174 validation of the source to library to executable needs to carefully
    175 managed so the application and RTEMS match. A verified and released
    176 RTEMS image can reduce this overhead and therefore provide cost
    177 savings over the life cycle of a project. Dynamic loading allows
    178 developers the ability to load debugging and support code into the
    179 system when running to help locate a problem. This is particularly
    180 useful when a project is in an integration or testing phase and
    181 something has gone wrong.
    182 
    183 Dynamic loading for RTEMS does not provide some of the advantages seen
    184 with virtual memory operating system such as Linux. On these systems
    185 dynamic loading allows code to be shared between separate
    186 processes. RTEMS is a single process operating system so there is
    187 nothing to sharing code with. Dynamic loading uses more
    188 resources. Memory is needed by the dynamic linker and space is needed
    189 on the target for the libraries if held locally. You need a working
    190 file system to read the code from into memory, plus there is the
    191 management of symbols. A potential down side of dynamic linking if not
    192 handle efficiently is the possible loading of a complete
    193 library. Virtual memory operating systems such as Linux avoid this
    194 issue by code sharing and demand loading executable files.
    195 
    196 In recent years Till Straumann has provided a separate package call
    197 cexp to allow loading of modules of code in RTEMS. His excellent
    198 package provides a similar model used in some commercial real-time
    199 operating systems. It how ever does not follow any of the standard
    200 APIs that RTEMS currently follows. It also provides custom solutions
    201 for some of the more complex issues that arise with dynamic loading of
    202 code. This code and his efforts provide an important base for this and
    203 future work related to dynamic loading in RTEMS. An important area he
    204 has solved is the management of targeted linking of libraries such as
    205 libc.
    206 
    207 The IEEE Std 1003.1-2004 standard defines [http://www.opengroup.org/onlinepubs/009695399/functions/dlopen.html  <dlfcn.h>]. This is a
    208 small API that makes an executable object file available to the
    209 calling program. The API calls are:
    210 
    211  int    dlclose(void *);
    212  char  *dlerror(void);
    213  void  *dlopen(const char *, int);
    214  void  *dlsym(void *restrict, const char *restrict);
    215 
    216 The functions provide an interface to the run-time linker and allow
    217 executable object files or shared object files to be loaded into a
    218 process's address space. RTEMS is a single process or single address
    219 space operating system so there is a close mapping to the needs of
    220 RTEMS.
    221 
    222 Some operating systems provide extra interfaces to help manage
    223 dynamically loaded object files. For example FreeBSD provides
    224 dlinfo. The RTEMS can provide these types of interfaces as
    225 implementation demands.
    226 
    227 The central component is the [http://www.freebsd.org/cgi/man.cgi?query=rtld&sektion=1 dynamic linker]. The dynamic linker
    228 provides run-time loading and link-editing of object files. The linker
    229 loads the object file code for all shared libraries into the process's
    230 address space performing any relocation, then proceeds to resolve
    231 external references from both the main program and all object files
    232 loaded. The linker calls initialisation routines for each object file
    233 loaded giving a shared object an opportunity to perform any extra
    234 set-up before execution of the program proper beings. C++ libraries
    235 that contain static constructors require this type of
    236 initialisation. The dynamic linker is specific to the ELF file
    237 format. This means the RTEMS object file format is ELF for targets
    238 that require dynamic loading of object files.
    239 
    240 The main application can be viewed as an object file that is required
    241 to loaded, relocated and initialised before being started. It can be
    242 considered the root of a tree of dynamically referenced object files
    243 loaded at run-time.
    244 =  =ynamic loading of code into a running RTEMS target has been a long
    245 term wish for many RTEMS users. Dynamic loading is not for all systems
    246 but systems with the resources to support it could make use the
    247 advantages it offers.
    248 
    249 Dynamic loading means a single binary release of RTEMS can be used by
    250 developers and production release teams. The same binary executable
    251 the application is developed and tested against can be the same binary
    252 executable placed into production. A single check sum can verify the
    253 image. If linking to create a single executable the verification and
    254 validation of the source to library to executable needs to carefully
    255 managed so the application and RTEMS match. A verified and released
    256 RTEMS image can reduce this overhead and therefore provide cost
    257 savings over the life cycle of a project. Dynamic loading allows
    258 developers the ability to load debugging and support code into the
    259 system when running to help locate a problem. This is particularly
    260 useful when a project is in an integration or testing phase and
    261 something has gone wrong.
    262 
    263 Dynamic loading for RTEMS does not provide some of the advantages seen
    264 with virtual memory operating system such as Linux. On these systems
    265 dynamic loading allows code to be shared between separate
    266 processes. RTEMS is a single process operating system so there is
    267 nothing to sharing code with. Dynamic loading uses more
    268 resources. Memory is needed by the dynamic linker and space is needed
    269 on the target for the libraries if held locally. You need a working
    270 file system to read the code from into memory, plus there is the
    271 management of symbols. A potential down side of dynamic linking if not
    272 handle efficiently is the possible loading of a complete
    273 library. Virtual memory operating systems such as Linux avoid this
    274 issue by code sharing and demand loading executable files.
    275 
    276 In recent years Till Straumann has provided a separate package call
    277 cexp to allow loading of modules of code in RTEMS. His excellent
    278 package provides a similar model used in some commercial real-time
    279 operating systems. It how ever does not follow any of the standard
    280 APIs that RTEMS currently follows. It also provides custom solutions
    281 for some of the more complex issues that arise with dynamic loading of
    282 code. This code and his efforts provide an important base for this and
    283 future work related to dynamic loading in RTEMS. An important area he
    284 has solved is the management of targeted linking of libraries such as
    285 libc.
    286 
    287 The IEEE Std 1003.1-2004 standard defines [http://www.opengroup.org/onlinepubs/009695399/functions/dlopen.html  <dlfcn.h>]. This is a
    288 small API that makes an executable object file available to the
    289 calling program. The API calls are:
    290 
    291  int    dlclose(void *);
    292  char  *dlerror(void);
    293  void  *dlopen(const char *, int);
    294  void  *dlsym(void *restrict, const char *restrict);
    295 
    296 The functions provide an interface to the run-time linker and allow
    297 executable object files or shared object files to be loaded into a
    298 process's address space. RTEMS is a single process or single address
    299 space operating system so there is a close mapping to the needs of
    300 RTEMS.
    301 
    302 Some operating systems provide extra interfaces to help manage
    303 dynamically loaded object files. For example FreeBSD provides
    304 dlinfo. The RTEMS can provide these types of interfaces as
    305 implementation demands.
    306 
    307 The central component is the [http://www.freebsd.org/cgi/man.cgi?query=rtld&sektion=1 dynamic linker]. The dynamic linker
    308 provides run-time loading and link-editing of object files. The linker
    309 loads the object file code for all shared libraries into the process's
    310 address space performing any relocation, then proceeds to resolve
    311 external references from both the main program and all object files
    312 loaded. The linker calls initialisation routines for each object file
    313 loaded giving a shared object an opportunity to perform any extra
    314 set-up before execution of the program proper beings. C++ libraries
    315 that contain static constructors require this type of
    316 initialisation. The dynamic linker is specific to the ELF file
    317 format. This means the RTEMS object file format is ELF for targets
    318 that require dynamic loading of object files.
    319 
    320 The main application can be viewed as an object file that is required
    321 to loaded, relocated and initialised before being started. It can be
    322 considered the root of a tree of dynamically referenced object files
    323 loaded at run-time.
    324 =  =The Task
    32590
    32691The task for RTEMS can be split in two, the host side and the target