Dynamic load real-time tasks

Chris Johns chrisj at rtems.org
Thu Jul 6 07:23:50 UTC 2017


On 04/07/2017 19:10, Павел Жданов wrote:
> 
> Thanks Chris. So far I can't solve this problem.
> I'm sorry for the stupid newbie questions but I just don't get the mechanism.

No need to apologize, if I could point you to some quality documentation I would
however I cannot at this point in time.

> I have a printf symbol in the base image dl.exe.

Great.

> I load the object file dl.o that uses printf. dl.o.

Symbol table?

> dl.c contains rtems_main and printf functions.

I assume you mean the 'dl.c' contains a reference to the 'printf' symbol and not
the 'printf' code.

> dl.o is obtained using the following command:
> 
> i386-rtems4.11-gcc -B$(RTEMS_MAKEFILE_PATH)lib/ -specs bsp_specs -qrtems
> -DHAVE_CONFIG_H -I.  -I..  -I./include -mtune=i486 -O2 -g -Wall
> -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes
> -Wnested-externs -MT dl.o -MD -MP -MF .deps/dl.Tpo -c -o dl.o dl.c

This looks OK.

> Symbol table dl-sym.o is obtained using the following commands:
>  
> i386-rtems4.11-gcc -B$(RTEMS_MAKEFILE_PATH)lib/ -specs bsp_specs -qrtems
> -mtune=i486 -O2 -g \
> -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes
> -Wnested-externs \
> -Wl,-Ttext,0x00100000  -mtune=i486 -o dl.pre init.o filesystem.o dl.o

You have linked in 'dl.o' to the kernel. If you link 'dl.o' to the kernel there
is no need to load it at run time because it will already be in memory. Lets
remove that object file, try:

 i386-rtems4.11-gcc -B$(RTEMS_MAKEFILE_PATH)lib/ -specs bsp_specs -qrtems
 -mtune=i486 -O2 -g \
 -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes
 -Wnested-externs \
 -Wl,-Ttext,0x00100000  -mtune=i486 -o kernel.pre init.o filesystem.o

> rtems-syms -e -c "-mtune=i486 -O2 -g -Wall -Wmissing-prototypes
> -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs" -o
> dl-sym.o dl.pre

Lets rewrite this command to reference the kernel we linked above in phase 1 of
the 2-pass link process:

 rtems-syms -e -c "-mtune=i486 -O2 -g -Wall -Wmissing-prototypes
 -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs" -o
 kernel-sym.o kernel.pre

You have now created an 'embedded' symbol table for the kernel. This object file
is a table of [address, string] where the 'address' is the symbol's address in
the kernel and the 'string' is the symbol. As an object these are unresolved
until you link it to the kernel in phase 2 of the link process. When we do the
linker will fill in the correct addresses for us:

 i386-rtems4.11-gcc -B$(RTEMS_MAKEFILE_PATH)lib/ -specs bsp_specs -qrtems
 -mtune=i486 -O2 -g \
 -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes
 -Wnested-externs \
 -Wl,-Ttext,0x00100000  -mtune=i486 -o kernel.exe init.o filesystem.o \
 kernel-sym.o

Now run 'kernel.exe' on your target.

Note, I have changed your use of 'dl' to 'kernel' in these commands because it
is the kernel that matters and not the code you are going to load at run time.
The kernel will be able to load any code, even code you have not yet written so
'dl.c' and 'dl.o' is just an example. You will not need to re-link the kernel
again to load other files.

Chris



More information about the users mailing list