Zynq and 4.11 dynamic loader

Tue Sep 8 22:26:19 UTC 2015

Hello Mathew,

On Tuesday 08 of September 2015 16:26:24 Mathew Benson wrote:
> I understand 4.11 has dynamic loader support, but only for PowerPC and
> MIPS(?).  Does anybody have dynamic loading working on the Zynq ARM?

there are sources for runtime dlopen for arm, i386, m68k,
powerpc, bfin, lm32, mips, sparc, h8300, m32r, moxie
and v850 included in RTEMS-4.11 rtems/cpukit/libdl.
I am not sure about status, dl01 and dl02 tests
are disabled only for some lm3s3749, lpc23xx and lpc2362
targets.

I have tested dlopen on i386 and arm in last week
to check what can be done with it and to find
memory requirements etc. Chris and others are much
more competent in this topic but I present results
of my playing there with hope that it could be
usesfull for somebody else.

I have included example application with dlopen shell command
test to RTEMS OMK template project

http://rtime.felk.cvut.cz/gitweb/rtems-devel.git

http://rtime.felk.cvut.cz/gitweb/rtems-devel.git/tree/refs/heads/master:/rtems-omk-template/appdl

Generally, next commands sequence should work for each
RTEMS board

git clone git://rtime.felk.cvut.cz/rtems-devel.git
cd rtems-devel/rtems-omk-template/
# setup target, i.e. path to directory where RTEMS support
# for given board is isntalled
echo "RTEMS_MAKEFILE_PATH=/opt/rtems4.11/arm-rtems4.11/lpc17xx_ea_ram" >config.target
# setup optional tests (dlopen is not enabled by default in my test)
cat >config.omk <<EOF
CONFIG_OC_APP_APPNET=y
CONFIG_OC_APP_APPNET_TELNETD=y
CONFIG_OC_APP_APPDL=y
CONFIG_OC_APP_APPDL_NET=y
CONFIG_OC_APP_APPDL_TELNETD=y
CONFIG_OC_APP_DL_PRINT=y
EOF

make

You find linked application with symbol table exported

_compiled/lpc17xx_ea_ram/bin/appdl

Inclusion of export table is controlled by per application
option applicationname_EXPORTSYMBOLS = y
You need rtems-sysms tool form https://git.rtems.org/rtems-tools/
repository installed.

The symbol table for ARM is build in my case (see "make V=1" output)
as linking application the first without symbol table (appdl.prelink)
and then generating symbol table by rtems-syms and linking with
appdl-symbol-table.o included.

Symbol table preparation command

rtems-syms -e -c "arm-rtems4.11-gcc --pipe -B/opt/rtems4.11/arm-rtems4.11/lpc17xx_ea_ram/lib/
  -specs bsp_specs -qrtems -march=armv7-m -mthumb
  -I /home/pi/tmp/rtems-devel/rtems-omk-template/_compiled/lpc17xx_ea_ram/include
  -Wall  -O2 -g  -I /home/pi/tmp/rtems-devel/rtems-omk-template/_build/lpc17xx_ea_ram/user/appdl"
  -S appdl-symbol-table.c -o appdl-symb      ol-table.o appdl.prelink

The most form the invocation is specification of C compiler
and its flags.

I have not prepared simple way to specify that some plugins,
shared objects should be compiled as relocatable ELFs for
our infrastructure yet. I probably try to define it as equivalent
of shared_LIBRARIES support which we have in Linux OMK variant.

I have used hack for testing now, where I link complete application
image, i.e. example for my board

_compiled/lpc17xx_ea_ram/bin-tests/appdl_print

and copy its (single) object file to IMFS initial data location

mkdir appdl/rootfs/bin
cp _build/lpc17xx_ea_ram/user/appdl/examples/appdl_print.o appdl/rootfs/bin

and rerun

make clean all

That way the relocatable object file can be found
in running shell in directory /bin and can be loaded

ls /bin
dlopen /bin/appdl_print.o main arg1 arg2 arg3

Example can include network, so loading over TFTP,
NFS or other RTEMS supported transports is possible
as well.

There are more related things which I have not
solved yet and would be happy for others ideas.

The main problem is that I would like to have
some generic kernel image which exports not only
actually used symbols but ideally all standard
POSIX calls and support functions as well as
RTEMS services.

One simple and naive solution, which I have tried,
is use of "-Xlinker --whole-archive" option
during appdl.prelink linking.
But that does not work there are more compnents
and device drivers which cannot be included
without application provided configuration tables
etc. I know that there has been some support
to build generic RTEMS kernel in past with
right set of symbols exported (Eric Norum, EPICS).
But I have newer tried that.

I can imagine to use NM on RTEMS and Newlib C/m
ibraries and select some reasonable way which
objects are providing generic APIs and link these
or ask their symbols as extrn during prelink
phase. But that is not much elegant either.

When I have tried to run dlopen more times on same
object then there is problem that some small amount
of memory is allocated each time, this means, that
use of dlopen directly from some scripting environment
without dlclose (which is risky, because called function
can create threads) would need some other protection
against multiple dlopen calls specifying same file.

But generally, I have been really pleased how simple
id RTEMS dlopen use and how far it is compliant
to POSIX/more heavy OSes al Linux.

Best wishes,

                Pavel Pisa

==================================================
 PiKRON s.r.o.       Phone/Fax: +420 284684676
 Kankovskeho 1235    Phone:     +420 234697622
 182 00 Praha 8      WWW:   http://www.pikron.com/
 Czech Republic      e-mail:  pikron at pikron.com
==================================================