Re: Отв.: Shared library link

Mon Sep 26 17:22:42 UTC 2011

The base image is built just like a standard RTEMS binary with the "Init" function. In my base image, I do some basic initialization, then I initialize and run the shell startup script. The base image uses the BSP linker script, which already locates it in an absolute location in memory. You may need to adjust the base image linker script to allow for some room to locate your applications.
The shell startup script will mount the eeprom/flash file system, then load and execute the first loadable binary image.
The loader can be a program that parses the elf file and copies the code and data to ram ( and clears the BSS ).

The loadable binary files are linked with a rule similar to this:

APP1_ADDRESS  =      0x01730000
APP1_ENTRYPT  =      APP1_AppMain

app1.elf: rtems.elf  app1.o
$(LINKER) $(APP_LD_FLAGS) -Rrtems.elf  -Ttext $(APP1_ADDRESS) -e$(APP1_ENTRYPT) -o app1.elf app1.o

Note that you do not need to link in any libs, because they should be in the base rtems.elf image.

You have to carefully manage the memory map where you locate each task. If one of them grows it will overlap the next task's space.

I also failed to mention the CEXP solution earlier:
http://www.slac.stanford.edu/%7Estrauman/rtems/cexp/index.html
This loader has worked well for me. I could not use it on my current application due to memory constraints.

So that all being said, I would still rather use a dynamic loader. Micro-managing the memory map and trying to determine what needs to be re-linked is a pain!

Alan

On Sep 26, 2011, at 8:58 AM, Oleg Moroz wrote:

Can you send me scripts to build base image with absolute memory addresses?
________________________________
From: "Cudmore, Alan P. (GSFC-5820)" <alan.p.cudmore at nasa.gov<mailto:alan.p.cudmore at nasa.gov>>
To: Oleg Moroz <oleg_moroz at yahoo.com<mailto:oleg_moroz at yahoo.com>>
Cc: Rtems <rtems-users at rtems.org<mailto:rtems-users at rtems.org>>
Sent: Monday, September 26, 2011 4:47 PM
Subject: Re: Отв.: Shared library link

I have a current RTEMS application that uses your method of separate binary image for each task.

Our application was developed under vxWorks which has a dynamic object loader. On RTEMS, I build a base "kernel image" that includes the BSP, startup code, network stack, and any functions that I need from the C or Math libraries.

Each application ( which is one or more RTEMS tasks ) is linked to an absolute memory location ( as you describe with your segmentation below ). Each task binary sets it's base address using the -T link option, it sets it's entry point using the -e link option, then it resolves it's external references by using the -R option to refer to the base image.

We developed a "static loader" which loads the binary file from a file system at runtime, and returns the application entry point. The base image/startup code can then create the RTEMS task to start the application.

This all works very well, but it does have drawbacks:
1. You must include any functions that your application needs into your base image. This can be done by a reference to a symbol.
2. If anything changes in the base image, you must re-link and re-load all of your applications or they will crash.

We intend to replace this in the future with the dynamic loader that Chris has mentioned.

Alan

On Sep 26, 2011, at 3:05 AM, Oleg Moroz wrote:

Thanks for answer. Sorry for my english.

>What happens when the size of the code changes ?

I'm developing my application with memory "segmentation". I mean:

0x40000000
--------------
main task
--------------

0x40001000 (for example)
-------------
second task
-------------

0x40002000
-------------
third task
-------------

0x4000f000
------------
functions like printf() and other common functions and data
------------

0x40001000-0x40000000 > sizeof(main task)
0x40002000-0x40001000 > sizeof(second task)
......

I mean what i must manually locate all of this tasks in memory, and allocate memory "segment" for every task. It will be doing by main task that could load task code from EEPROM. I'm trying to create mechanism to dynamically loading and unloading tasks like it did in usual OSes with processes. This mechanism need not be universally. It only for this project now.

>I suggest you take a look at:
>
>http://www.rtems.org/ftp/pub/rtems/people/chrisj/rtl/

Thanks. Now i'm downloading archive from this directory, and will see what is it.

>In the traditional definition dynamic and static libraries are not the same type of code. They can varying depending on the specific method used by the operating system. As Joel stated RTEMS is a single address space or processes and will not support the Unix
>(ELF) shared library model. It adds overhead for no gain. Given this I am not sure I understand your sentence. For example have you built shared RTEMS libraries (the tools will let you do this) and static libraries and are you attempting to mix the results ?

I will try.
________________________________
From: Chris Johns <chrisj at rtems.org<mailto:chrisj at rtems.org>>
To: Oleg Moroz <oleg_moroz at yahoo.com<mailto:oleg_moroz at yahoo.com>>
Cc: Rtems <rtems-users at rtems.org<mailto:rtems-users at rtems.org>>
Sent: Monday, September 26, 2011 2:48 AM
Subject: Re: Отв.: Shared library link

On 24/09/11 4:01 PM, Oleg Moroz wrote:
> Okay. The reason why i want extract functions from shared or static
> library is dynamical achange parts of code.

In the traditional definition dynamic and static libraries are not the same type of code. They can varying depending on the specific method used by the operating system. As Joel stated RTEMS is a single address space or processes and will not support the Unix (ELF) shared library model. It adds overhead for no gain. Given this I am not sure I understand your sentence. For example have you built shared RTEMS libraries (the tools will let you do this) and static libraries and are you attempting to mix the results ?

> Now i have small app than
> can parse elf file and extract machine code of ever Task (or another
> functions).

I suggest you take a look at:

http://www.rtems.org/ftp/pub/rtems/people/chrisj/rtl/

I have a host based linker in development. I thought I had a copy on the server but I do not. I will upload a version soon.

The path I have taken to create a runtime link editor in RTEMS that can load ELF relocatable object files directly or from archive files and resolve any external symbols as well as export any suitable symbols. This is all via the dlopen call. I have an RTEMS linker in development which handles the dependence resolution providing a suitable meta-data format. This project is still in development.

Note, this RTEMS project uses waf so check the README.

> Problem is what the addresses of all functions in the
> recompiled project (with some bug fixes or functionality added) are not
> the same with original project.

The object files are relocatable. You need a link editor to locate the object files and fix up the addresses.

> I must fix it manually, but this is the
> easiest way to make an error. I think than i can create the library with
> all functions. and addresses of that funcs are constant.

What happens when the size of the code changes ?

> after this i
> could link it with my extracted updated task. extract task again,
> and overwrite it on working RTEMS. Maybe linker or compiler has some
> command switch? Something like - Ttext=0x40100000

Sorry, but I do not understand this.

Chris

_______________________________________________
rtems-users mailing list
rtems-users at rtems.org<mailto:rtems-users at rtems.org>
http://www.rtems.org/mailman/listinfo/rtems-users

_______________________________________________
rtems-users mailing list
rtems-users at rtems.org<mailto:rtems-users at rtems.org>
http://www.rtems.org/mailman/listinfo/rtems-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20110926/759f3913/attachment-0001.html>