Re: Отв.: Shared library link

Mon Sep 26 12:47:44 UTC 2011

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

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