Changes between Version 6 and Version 7 of Projects/libdl


Ignore:
Timestamp:
Feb 7, 2010, 9:18:39 PM (10 years ago)
Author:
JoelSherrill
Comment:

Add Status

Legend:

Unmodified
Added
Removed
Modified
  • Projects/libdl

    v6 v7  
    55[[TOC(Projects/libdl, depth=2)]]
    66
     7
     8'''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.
    79
    810Dynamic 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.
     
    5254
    5355A 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.
     56= Open Projects =
     57
     58
     59There 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.
     60
     61 *  load simple dynamic library and execute method
     62 *  load simple dynamic library, execute method and it call a method in the base image (e.g. printf)
     63 *  load two dynamic libraries, have the second depend on a symbol in the first and have it work.
     64
     65[wiki:User::JoelSherrill  Joel Sherrill] has tests for the above.
     66
     67The RTEMS port supports i386 and SPARC.  We need more architectures.  Updating the source and remerging our extra targets will resolve some of these. 
     68
     69The 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.
     70
     71The current source is available via:
     72
     73{{{
     74git clone git://github.com/absabs/objdl
     75}}}
     76
     77The original Android source is available here.  This is NOT the version the above code is based upon. 
     78
     79{{{
     80http://android.git.kernel.org/?p=platform/bionic.git;a=tree;f=linker;h=39b12066c60cfc2748fa2a3b0d7903966ac7ad5b;hb=HEAD
     81}}}
    5482= References =
    5583