Dynamic load real-time tasks

Павел Жданов paul.alex.zhdanov at gmail.com
Thu Jul 6 17:05:10 UTC 2017


On Thu, Jul 6, 2017 at 10:23 AM, Chris Johns <chrisj at rtems.org> wrote:


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

I load it using dlopen() function.


>
> > 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.
>

Yes.


>  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
>

Chris, thanks a lot. I think that It works!!!

Before I noticed this email I decided to try another method. I didn't use
2-pass linking. I just created kernel-sym.o and loaded it by the kernel
(using dlopen) before loading the dl.o. I don't know if it is right but It
also helped.
As I understand now these two methods are described in rtems-syms
documentation (
https://ftp.rtems.org/pub/rtems/people/chrisj/docs/user/tools/symbols.html).
I just didn't understand how to use them.
At the moment I don't understand the difference between the kernel.pre and
kernel.exe (kernel.pre linked against symbol table) but I'll get it later.




*if I could point you to some quality documentation I would   however I
cannot at this point in time.*
To be honest, I didn't read all documentation about rtl. I began to read
sources to understand how it works. I thought that may be I could try to
add some simple examples (in addition to dl-0x) to rtems-syms documentation
to make it more clear for such new users as I am. Is it possible? How to do
it? Via new tickets at devel.rtems.org or somehow else?

Best regards,
Pavel Zhdanov.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20170706/de79c296/attachment.html>


More information about the users mailing list