Отв.: Shared library link

Till Straumann strauman at slac.stanford.edu
Mon Sep 26 20:00:19 UTC 2011 

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

More information about the users mailing list