Changes between Version 6 and Version 7 of Projects/libdl

Timestamp:

02/07/10 21:18:39 (14 years ago)

Author:

JoelSherrill

Comment:

Add Status

Projects/libdl

@@ -5 +5 @@
 [[TOC(Projects/libdl, depth=2)]]
 
+
+'''Status:''' Android Bison libc dlfnc.h functionality ported to RTEMS.  Simple examples work but important use cases do not.  Needs to support more CPU architectures.
 
 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.
@@ -52 +54 @@
 
 A 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.
+= Open Projects =
+
+
+There is a port of the Android libc functionality to RTEMS.  It can be used to successfully load and execute a method in a simple dynamic library.  The following use cases must be satisfied before the code can be considered ready for inclusion in RTEMS.
+
+ *  load simple dynamic library and execute method
+ *  load simple dynamic library, execute method and it call a method in the base image (e.g. printf)
+ *  load two dynamic libraries, have the second depend on a symbol in the first and have it work.
+
+[wiki:User::JoelSherrill  Joel Sherrill] has tests for the above.
+
+The RTEMS port supports i386 and SPARC.  We need more architectures.  Updating the source and remerging our extra targets will resolve some of these.  
+
+The Android source has a different structure for addressing per-target issues.  We should track their code, add our own targets and submit to them.  They have ARM, SuperH, and x86.  We could submit SPARC.  There is a MIPS Android port we could leverage and push to get merged into the main repository.
+
+The current source is available via:
+
+{{{
+git clone git://github.com/absabs/objdl
+}}} 
+
+The original Android source is available here.  This is NOT the version the above code is based upon.  
+
+{{{
+http://android.git.kernel.org/?p=platform/bionic.git;a=tree;f=linker;h=39b12066c60cfc2748fa2a3b0d7903966ac7ad5b;hb=HEAD
+}}}
 = References =