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 |