Re: Отв.: Shared library link
Oleg Moroz
oleg_moroz at yahoo.com
Tue Sep 27 05:17:40 UTC 2011
Thanks. It's very interesting project.
>________________________________
>From: Till Straumann <strauman at slac.stanford.edu>
>To: "Cudmore, Alan P. (GSFC-5820)" <alan.p.cudmore at nasa.gov>
>Cc: Oleg Moroz <oleg_moroz at yahoo.com>; Rtems <rtems-users at rtems.org>
>Sent: Tuesday, September 27, 2011 12:00 AM
>Subject: Re: Отв.: Shared library link
>
>I didn't follow this thread closely and maybe I'm a bit off-topic
>but I just wanted to mention that I use my own variant of a run-time
>linker and symbol-table tool (web-page probably doesn't have the
>latest version):
>
>http://www.slac.stanford.edu/~strauman/rtems/cexp/index.html
>
>It has been in use for many years now at some major research
>facilities (particle accelerators).
>
>FWIW
>-- Till
>
>On 09/26/2011 12:22 PM, Cudmore, Alan P. (GSFC-5820) wrote:
>> 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 dynamicallyloading 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
>>
>>
>>
>> _______________________________________________
>> rtems-users mailing list
>> 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/20110927/c8c48521/attachment-0001.html>
More information about the users
mailing list