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


More information about the users mailing list