rtems dynamic loading with waf

Thu Dec 29 09:25:18 UTC 2016

Dear Chris,
For now, I use rtems-ld to generate my application. I have my base kernel, bkv01.elf, and my application, dl-01.c. 

First, I compiled my application without linking: 
# arm-rtems4.11-gcc ${CFLAGS1} -o dl-01.o -c dl-01.c
Then, I used rtems-ld to generate my loadable RAP: (something like below, please ignore the libs I added)
# rtems-ld -v --base bkv01.elf -e hello_world dl-01.o  -o app01.rap -L /opt/rtems-4.11.1-release/4.11-bsp/arm-rtems4.11/xilinx_zynq_zedboard/lib/ -lbsd -lrtemsbsp -lrtemscpu -ljffs2 -lrtems++ -lz

base-image: bkv01.elf
cache:load-sym: object files: 1
cache:load-sym: symbols: 10688
Finding libraries:
 found: ./libbsd.a
 found: /opt/rtems-4.11.1-release/4.11-bsp/arm-rtems4.11/xilinx_zynq_zedboard/lib/librtemsbsp.a
 found: /opt/rtems-4.11.1-release/4.11-bsp/arm-rtems4.11/xilinx_zynq_zedboard/lib/librtemscpu.a
 found: /opt/rtems-4.11.1-release/4.11-bsp/arm-rtems4.11/xilinx_zynq_zedboard/lib/libjffs2.a
 found: /opt/rtems-4.11.1-release/4.11-bsp/arm-rtems4.11/xilinx_zynq_zedboard/lib/librtems++.a
 found: /opt/rtems-4.11.1-release/4.11-bsp/arm-rtems4.11/xilinx_zynq_zedboard/lib/libz.a
cc::stdlib: libgcc.a
cc::stdlib: libssp.a
cc::stdlib: libc.a
cache:load-sym: object files: 4513
cache:load-sym: symbols: 12987
resolver:resolving:  undefines, unresolved: 1
resolver:resolve  :    |- hello_world
resolver:resolved :    |   `--> dl-01.o (unresolved: 1)
resolver:resolved :    +-- referenced objects: 1
resolver:resolving:  ] undefines ==> dl-01.o
resolver:resolving:  dl-01.o, unresolved: 7
resolver:resolve  :     |- __getreent
resolver:resolved :     |   `--> bkv01.elf (base)
resolver:resolve  :     |- fprintf
resolver:resolved :     |   `--> bkv01.elf (base)
resolver:resolve  :     |- puts
resolver:resolved :     |   `--> bkv01.elf (base)
resolver:resolve  :     |- rtems_status_text
resolver:resolved :     |   `--> bkv01.elf (base)
resolver:resolve  :     |- rtems_task_create
resolver:resolved :     |   `--> bkv01.elf (base)
resolver:resolve  :     |- rtems_task_delete
resolver:resolved :     |   `--> bkv01.elf (base)
resolver:resolve  :     |- rtems_task_start
resolver:resolved :     |   `--> bkv01.elf (base)
resolver:resolved :     +-- referenced objects: 0
resolver:resolving: top: dl-01.o
resolver:resolving:  dl-01.o is resolved or resolving
resolver:resolving: dependents: 1
  1: dl-01.o
outputter:application: app01.rap
rap::layout: total:654 text:380 const:178 ctor:0 dtor:0 data:0 bss:0 symbols:12 (1) strings:26 relocs:59
rap:output: machine=0
rap:output: header=12
rap:output: .text: offset=177 size=380
rap:output: .const: offset=557 size=178
rap:output: .ctor: offset=735 size=0
rap:output: .dtor: offset=735 size=0
rap:output: .data: offset=735 size=0
rap:output: strtab=735
rap:output: symbols=761
rap:output: relocs=773
rap: objects: 1, size: 881, compression: 54.7%

And, I got the RAP format file I want. This RAP would be downloaded into my system filesystem via FTP (just make rtems as server, and my host as client). 
Finally, I loaded this RAP file with dlopen, then an error came up:
    dlopen failed: global symbol not found: puts

Is there something wrong with my attempt? If so, please give my some advise, thanks a lot.

Best wishes,

xuelin.tian at qkmtech.com

From: Chris Johns
Date: 2016-12-29 16:52
To: Saeed Ehteshamifar; xuelin.tian at qkmtech.com
CC: users at rtems.org
Subject: Re: rtems dynamic loading with waf
On 28/12/16 9:36 pm, Saeed Ehteshamifar wrote:
> Dear Xuelin,
> 
> I share the pointers I emailed you here. Maybe it'd be useful for
> someone else too.
> Instructions on how to build a DL app via WAF can be found at:
> http://rtems-fi.blogspot.com/2016/08/dynamic-linking-in-rtems.html

The blog post is not correct about loading being restricted due to
transferring object files on the fly. RTEMS will load any available obj
file and object files do not need to be bound into the base image using
tar, they just need to be available in a suitable file system. The
examples and tests bind the object files into the base image because we
cannot assume available media on a target, eg a simulator. A target with
a file system such as JFFS and networking could be updated externally
and the object files loaded from the JFFS file system.

The fact we require the same compiler flags to build the loadable object
file is a requirement, important and a feature. Code loaded by RTEMS's
libdl is the same as statically linked code so the performance is the
same. There is no difference in call overheads or access to global data
and this means you get the same performance as being statically linked.
RTEMS is a single address space and we need all code to be built the
same way, I consider anything else as risky.

> Disclaimer: An "unresolved external" error was encountered at run-time,
> after building the DL app via the above instructions.

The shell command should be able to print a list of unresolved symbols.

> The link also encompasses instructions on how to build a DL app via OMK,
> as an alternative to WAF. The OMK DL app ran without an error.
> 
> It'd be nice if you, or anyone who successfully builds a DL app via WAF,
> share the code/instructions here because AFAIK there's no such example
> in the RTEMS repository/wiki.

The following is the waf build script I used to develop libdl.

https://git.rtems.org/chrisj/rtl.git/tree/wscript

The libdl support and building for it is complicated and there is a wide
of things that are possible. Good documentation is needed and something
I would like to see exist.

Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20161229/2349c215/attachment-0001.html>