<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div><span><br></span></div><div>Thanks. It's very interesting project.<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><div style="font-size: 12pt; font-family: 'times new roman', 'new york', times, serif; "><div style="font-size: 12pt; font-family: 'times new roman', 'new york', times, serif; "><font size="2" face="Arial"><hr size="1"><b><span style="font-weight:bold;">From:</span></b> Till Straumann <strauman@slac.stanford.edu><br><b><span style="font-weight: bold;">To:</span></b> "Cudmore, Alan P. (GSFC-5820)" <alan.p.cudmore@nasa.gov><br><b><span style="font-weight: bold;">Cc:</span></b> Oleg Moroz <oleg_moroz@yahoo.com>; Rtems <rtems-users@rtems.org><br><b><span style="font-weight: bold;">Sent:</span></b> Tuesday, September 27, 2011 12:00
AM<br><b><span style="font-weight: bold;">Subject:</span></b> Re: Отв.: Shared library link<br></font><br>I didn't follow this thread closely and maybe I'm a bit off-topic<br>but I just wanted to mention that I use my own variant of a run-time<br>linker and symbol-table tool (web-page probably doesn't have the<br>latest version):<br><br><a href="http://www.slac.stanford.edu/~strauman/rtems/cexp/index.html" target="_blank">http://www.slac.stanford.edu/~strauman/rtems/cexp/index.html</a><br><br>It has been in use for many years now at some major research<br>facilities (particle accelerators).<br><br>FWIW<br>-- Till<br><br>On 09/26/2011 12:22 PM, Cudmore, Alan P. (GSFC-5820) wrote:<br>> The base image is built just like a standard RTEMS binary with the<br>> "Init" function. In my base image, I do some basic initialization, then<br>> I initialize and run the shell startup script. The base image uses the<br>> BSP linker script, which already
locates it in an absolute location in<br>> memory. You may need to adjust the base image linker script to allow for<br>> some room to locate your applications.<br>> The shell startup script will mount the eeprom/flash file system, then<br>> load and execute the first loadable binary image.<br>> The loader can be a program that parses the elf file and copies the code<br>> and data to ram ( and clears the BSS ).<br>><br>> The loadable binary files are linked with a rule similar to this:<br>><br>> APP1_ADDRESS = 0x01730000<br>> APP1_ENTRYPT = APP1_AppMain<br>><br>> app1.elf: rtems.elf app1.o<br>> $(LINKER) $(APP_LD_FLAGS) -Rrtems.elf -Ttext $(APP1_ADDRESS)<br>> -e$(APP1_ENTRYPT) -o app1.elf app1.o<br>><br>> Note that you do not need to link in any libs, because they should be in<br>> the base rtems.elf image.<br>><br>> You have to carefully manage the memory map where you locate each task.<br>>
If one of them grows it will overlap the next task's space.<br>><br>> I also failed to mention the CEXP solution earlier:<br>> <a href="http://www.slac.stanford.edu/%7Estrauman/rtems/cexp/index.html" target="_blank">http://www.slac.stanford.edu/%7Estrauman/rtems/cexp/index.html</a><br>> This loader has worked well for me. I could not use it on my current<br>> application due to memory constraints.<br>><br>> So that all being said, I would still rather use a dynamic loader.<br>> Micro-managing the memory map and trying to determine what needs to be<br>> re-linked is a pain!<br>><br>> Alan<br>><br>><br>> On Sep 26, 2011, at 8:58 AM, Oleg Moroz wrote:<br>><br>>> Can you send me scripts to build base image with absolute memory<br>>> addresses?<br>>><br>>> ------------------------------------------------------------------------<br>>> *From:* "Cudmore, Alan
P. (GSFC-5820)" <<a ymailto="mailto:alan.p.cudmore@nasa.gov" href="mailto:alan.p.cudmore@nasa.gov">alan.p.cudmore@nasa.gov</a><br>>> <mailto:<a ymailto="mailto:alan.p.cudmore@nasa.gov" href="mailto:alan.p.cudmore@nasa.gov">alan.p.cudmore@nasa.gov</a>>><br>>> *To:* Oleg Moroz <<a ymailto="mailto:oleg_moroz@yahoo.com" href="mailto:oleg_moroz@yahoo.com">oleg_moroz@yahoo.com</a> <mailto:<a ymailto="mailto:oleg_moroz@yahoo.com" href="mailto:oleg_moroz@yahoo.com">oleg_moroz@yahoo.com</a>>><br>>> *Cc:* Rtems <<a ymailto="mailto:rtems-users@rtems.org" href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a> <mailto:<a ymailto="mailto:rtems-users@rtems.org" href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a>>><br>>> *Sent:* Monday, September 26, 2011 4:47 PM<br>>> *Subject:* Re: Отв.: Shared library
link<br>>><br>>> I have a current RTEMS application that uses your method of<br>>> separate binary image for each task.<br>>><br>>> Our application was developed under vxWorks which has a dynamic<br>>> object loader. On RTEMS, I build a base "kernel image" that<br>>> includes the BSP, startup code, network stack, and any functions<br>>> that I need from the C or Math libraries.<br>>><br>>> Each application ( which is one or more RTEMS tasks ) is linked to<br>>> an absolute memory location ( as you describe with your<br>>> segmentation below ). Each task binary sets it's base address<br>>> using the -T link option, it sets it's entry point using the -e<br>>> link option, then it resolves it's external references by
using<br>>> the -R option to refer to the base image.<br>>><br>>> We developed a "static loader" which loads the binary file from a<br>>> file system at runtime, and returns the application entry point.<br>>> The base image/startup code can then create the RTEMS task to<br>>> start the application.<br>>><br>>> This all works very well, but it does have drawbacks:<br>>> 1. You must include any functions that your application needs into<br>>> your base image. This can be done by a reference to a symbol.<br>>> 2. If anything changes in the base image, you must re-link and<br>>> re-load all of your applications or they will crash.<br>>><br>>> We intend to replace this in the future with the dynamic loader<br>>>
that Chris has mentioned.<br>>><br>>> Alan<br>>><br>>><br>>> On Sep 26, 2011, at 3:05 AM, Oleg Moroz wrote:<br>>><br>>>> Thanks for answer. Sorry for my english.<br>>>><br>>>> >What happens when the size of the code changes ?<br>>>><br>>>> I'm developing my application with memory "segmentation". I mean:<br>>>><br>>>> 0x40000000<br>>>> --------------<br>>>> main task<br>>>> --------------<br>>>><br>>>> 0x40001000 (for example)<br>>>> -------------<br>>>> second task<br>>>> -------------<br>>>><br>>>> 0x40002000<br>>>>
-------------<br>>>> third task<br>>>> -------------<br>>>><br>>>> 0x4000f000<br>>>> ------------<br>>>> functions like printf() and other common functions and data<br>>>> ------------<br>>>><br>>>><br>>>> 0x40001000-0x40000000 > sizeof(main task)<br>>>> 0x40002000-0x40001000 > sizeof(second task)<br>>>> ......<br>>>><br>>>> I mean what i must manually locate all of this tasks in memory,<br>>>> and allocate memory "segment" for every task. It will be doing by<br>>>> main task that could load task code from EEPROM. I'm trying to<br>>>> create mechanism to dynamicallyloading and unloading tasks like<br>>>>
it did in usual OSes with processes. This mechanism need not be<br>>>> universally. It only for this project now.<br>>>><br>>>> >I suggest you take a look at:<br>>>> ><br>>>> ><a href="http://www.rtems.org/ftp/pub/rtems/people/chrisj/rtl/" target="_blank">http://www.rtems.org/ftp/pub/rtems/people/chrisj/rtl/</a><br>>>><br>>>> Thanks. Now i'm downloading archive from this directory, and will<br>>>> see what is it.<br>>>><br>>>><br>>>> >In the traditional definition dynamic and static libraries are<br>>>> not the same type of code. They can varying depending on the<br>>>> specific method used by the operating system. As Joel stated<br>>>> RTEMS is a single address space or
processes and will not support<br>>>> the Unix<br>>>> >(ELF) shared library model. It adds overhead for no gain. Given<br>>>> this I am not sure I understand your sentence. For example have<br>>>> you built shared RTEMS libraries (the tools will let you do this)<br>>>> and static libraries and are you attempting to mix the results ?<br>>>><br>>>> I will try.<br>>>><br>>>> ------------------------------------------------------------------------<br>>>> *From:* Chris Johns <<a ymailto="mailto:chrisj@rtems.org" href="mailto:chrisj@rtems.org">chrisj@rtems.org</a> <mailto:<a ymailto="mailto:chrisj@rtems.org" href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>>><br>>>> *To:* Oleg
Moroz <<a ymailto="mailto:oleg_moroz@yahoo.com" href="mailto:oleg_moroz@yahoo.com">oleg_moroz@yahoo.com</a><br>>>> <mailto:<a ymailto="mailto:oleg_moroz@yahoo.com" href="mailto:oleg_moroz@yahoo.com">oleg_moroz@yahoo.com</a>>><br>>>> *Cc:* Rtems <<a ymailto="mailto:rtems-users@rtems.org" href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a><br>>>> <mailto:<a ymailto="mailto:rtems-users@rtems.org" href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a>>><br>>>> *Sent:* Monday, September 26, 2011 2:48 AM<br>>>> *Subject:* Re: Отв.: Shared library link<br>>>><br>>>> On 24/09/11 4:01 PM, Oleg Moroz wrote:<br>>>> > Okay. The reason why i want extract
functions from shared or<br>>>> static<br>>>> > library is dynamical achange parts of code.<br>>>><br>>>> In the traditional definition dynamic and static libraries<br>>>> are not the same type of code. They can varying depending on<br>>>> the specific method used by the operating system. As Joel<br>>>> stated RTEMS is a single address space or processes and will<br>>>> not support the Unix (ELF) shared library model. It adds<br>>>> overhead for no gain. Given this I am not sure I understand<br>>>> your sentence. For example have you built shared RTEMS<br>>>> libraries (the
tools will let you do this) and static<br>>>> libraries and are you attempting to mix the results ?<br>>>><br>>>> > Now i have small app than<br>>>> > can parse elf file and extract machine code of ever Task (or<br>>>> another<br>>>> > functions).<br>>>><br>>>> I suggest you take a look at:<br>>>><br>>>> <a href="http://www.rtems.org/ftp/pub/rtems/people/chrisj/rtl/" target="_blank">http://www.rtems.org/ftp/pub/rtems/people/chrisj/rtl/</a><br>>>><br>>>> I have a host based linker in development. I thought I had a<br>>>> copy on the server but I do not. I will upload a version
soon.<br>>>><br>>>> The path I have taken to create a runtime link editor in<br>>>> RTEMS that can load ELF relocatable object files directly or<br>>>> from archive files and resolve any external symbols as well<br>>>> as export any suitable symbols. This is all via the dlopen<br>>>> call. I have an RTEMS linker in development which handles the<br>>>> dependence resolution providing a suitable meta-data format.<br>>>> This project is still in development.<br>>>><br>>>> Note, this RTEMS project uses waf so check the README.<br>>>><br>>>> > Problem is what the addresses of all functions in
the<br>>>> > recompiled project (with some bug fixes or functionality<br>>>> added) are not<br>>>> > the same with original project.<br>>>><br>>>> The object files are relocatable. You need a link editor to<br>>>> locate the object files and fix up the addresses.<br>>>><br>>>> > I must fix it manually, but this is the<br>>>> > easiest way to make an error. I think than i can create the<br>>>> library with<br>>>> > all functions. and addresses of that funcs are constant.<br>>>><br>>>> What happens when the size of the code changes
?<br>>>><br>>>> > after this i<br>>>> > could link it with my extracted updated task. extract task<br>>>> again,<br>>>> > and overwrite it on working RTEMS. Maybe linker or compiler<br>>>> has some<br>>>> > command switch? Something like - Ttext=0x40100000<br>>>><br>>>> Sorry, but I do not understand this.<br>>>><br>>>> Chris<br>>>><br>>>><br>>>> _______________________________________________<br>>>> rtems-users mailing list<br>>>> <a ymailto="mailto:rtems-users@rtems.org" href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a>
<mailto:<a ymailto="mailto:rtems-users@rtems.org" href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a>><br>>>> <a href="http://www.rtems.org/mailman/listinfo/rtems-users" target="_blank">http://www.rtems.org/mailman/listinfo/rtems-users</a><br>>><br>>><br>>><br>>> _______________________________________________<br>>> rtems-users mailing list<br>>> <a ymailto="mailto:rtems-users@rtems.org" href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a> <mailto:<a ymailto="mailto:rtems-users@rtems.org" href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a>><br>>> <a href="http://www.rtems.org/mailman/listinfo/rtems-users" target="_blank">http://www.rtems.org/mailman/listinfo/rtems-users</a><br>><br>><br>><br>> _______________________________________________<br>> rtems-users mailing list<br>> <a ymailto="mailto:rtems-users@rtems.org"
href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a><br>> <a href="http://www.rtems.org/mailman/listinfo/rtems-users" target="_blank">http://www.rtems.org/mailman/listinfo/rtems-users</a><br><br><br></div></div></blockquote></div></div></body></html>