dynamic loading in 4.11
oleg.moroz at aol.com
Fri Dec 2 10:01:39 UTC 2011
Thanks for this full answer. Are this tools can work only with rtems-4.11?
On 02.12.2011 11:31, Chris Johns wrote:
> On 2/12/11 7:42 PM, Oleg Moroz wrote:
>> Hello everyone. I want to try announced dynamical code loading. How can
>> i do that? I've checkout source code from CSV, but there is no dlfcn.h
> The projects current status can be download from here:
> Please download the latest version.
>> Is this functionality in main branch?
> No. I develop outside the main source tree and integrate once
> completed. I do this to speed up the development edit->compile cycle.
> There are 2 parts to the project. The target side (rtl-<date>.tar.bz2)
> and host side (rtl-host-<date>.tar.bz2). You need both parts.
> The current status is:
> 1. The target side will load sparc, i386 and m68k and arm support is
> provided but I have not tested it. There is stubs for the NIOS target
> but it will not load.
> 2. The target side needs support to handle object files loaded with
> unresolved externals. This can occur if 2 object modules depend on
> each other. One needs to be loaded with the error and resolved once
> the other module is loaded. This means there needs to some memory put
> aside for the unresolved symbols and that complicates the management
> of the memory. I need to add support for a memory pool for the loader
> and to move all allocations to the pool. Memory is a critical issue to
> make sure the heap does not fragment.
> 3. The target code needs to have the allocator hooks added so custom
> allocators can be used when loading. This will allow for specific
> locations to be used when loading and MMU support to write protect the
> code if this is a requirement. That functionality is outside the loader.
> 4. The host code is a linker called rtems-ld. It is used to create
> either a script file that lists the object modules to load or create
> an archive or object modules. The archive is a direct copy of the
> object files in the libraries and contain the debugging data. The
> archive needs to be stripped.
> 5. The rtems-ld linker now support the elftoolchain libelf package.
> This is used in FreeBSD and other projects and is a high quality
> active libelf package. It contains a strip tool that can strip
> archives and therefore can strip the output of the RTEMS linker. I
> have ported the package to Darwin and Windows and I am currently
> preparing patches to submit back to the project. The rtl-host package
> I have contain the libelf source and is self contained. I have tested
> Linux, MacOS, Windows and FreeBSD.
> 6. Debugging support for code loaded needs to be figured out.
> The target and host code uses waf as a build system. You can find waf
> here http://code.google.com/p/waf/. The host build is:
> $ tar jxf rtl-host-20111124.tar.bz2
> $ cd rtl-host-20111124
> $ waf configure build
> The target code is:
> $ tar jxf rtl-20111005.tar.bz2
> $ cd rtl-20111005
> $ waf configure \
> --rtems=/Users/chris/Development/rtems/build/4.11 \
> where '--rtems=' is the path to installed board support packages such
> as SIS and '--rtems-tools=' is a list of paths to tools. I have NIOS
> tools installed and a built NIOS BSP. This builds an application you
> can run and it will have 'dlo' and other commands.
> The target code uses the pkgconfig files RTEMS creates. The package
> config support in RTEMS is experimental support.
> The linker is invoked with something like:
> $ ./build-darwin/rtems-ld -v
> -lrtemsbsp -lrtemscpu -lm -b
> RTEMS Linker 1.0.0
> Finding libraries:
> gcc::stdlib: libgcc.a
> gcc::stdlib: libssp.a
> gcc::stdlib: libc.a
> resolver:resolving: top:
> x-long-name-to-create-gnu-extension-in-archive.c.2.o, unresolved: 4
> resolver:resolved : exit -> rtld
> resolver:resolved : printf -> rtld
> resolver:resolved : puts -> rtld
> resolver:resolved : sin -> libm.a:lib_a-s_sin.o at 805916
> resolver:resolving: libm.a:lib_a-s_sin.o at 805916, unresolved: 3
> resolver:resolved : __ieee754_rem_pio2 ->
> libm.a:lib_a-e_rem_pio2.o at 304536
> resolver:resolved : __kernel_cos -> libm.a:lib_a-k_cos.o at 511700
> resolver:resolved : __kernel_sin -> libm.a:lib_a-k_sin.o at 524656
> resolver:resolving: libm.a:lib_a-e_rem_pio2.o at 304536, unresolved: 2
> resolver:resolved : __kernel_rem_pio2 ->
> libm.a:lib_a-k_rem_pio2.o at 516224
> resolver:resolved : fabs -> libm.a:lib_a-s_fabs.o at 655520
> resolver:resolving: libm.a:lib_a-k_rem_pio2.o at 516224, unresolved: 2
> resolver:resolved : floor -> libm.a:lib_a-s_floor.o at 665352
> resolver:resolved : scalbn -> libm.a:lib_a-s_scalbn.o at 795192
> resolver:resolving: libm.a:lib_a-s_floor.o at 665352, unresolved: 0
> resolver:resolving: libm.a:lib_a-s_scalbn.o at 795192, unresolved: 1
> resolver:resolved : copysign -> libm.a:lib_a-s_copysign.o at 625924
> resolver:resolving: libm.a:lib_a-s_copysign.o at 625924, unresolved: 0
> resolver:resolving: libm.a:lib_a-s_fabs.o at 655520, unresolved: 0
> resolver:resolving: libm.a:lib_a-k_cos.o at 511700, unresolved: 0
> resolver:resolving: libm.a:lib_a-k_sin.o at 524656, unresolved: 0
> outputter:archive: a.out
> You could now load a.out using the 'dlo' command and then call
> functions in the loaded code.
> All this code is experimental so please be warned.
More information about the users