Re: Отв.: Shared library link

[Oleg Moroz]

>I did wonder if this was the approach. It does still seem a little fragile.

yes it's fragile. Because of this i'm finding better way.


>Is this to occur without RTEMS restarting ?
Yes, without restarting.

>Where is the code to manage this located and what happens with the heap.
this code is located in main task (the task what starting and manage all another tasks). About heap. In the simple examples everything okay. Maybe i should rewrite the heap manager to consider the memory "segmentation". 


>________________________________
>From: Chris Johns <chrisj at rtems.org>
>To: Oleg Moroz <oleg_moroz at yahoo.com>
>Cc: Rtems <rtems-users at rtems.org>
>Sent: Monday, September 26, 2011 12:23 PM
>Subject: Re: Отв.: Shared library link
>
>On 26/09/11 5:05 PM, Oleg Moroz wrote:
>> Thanks for answer. Sorry for my english.
>
>I understand. I will attempt to clearly state any assumptions on my part.
>
>>
>>  >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.
>
>I did wonder if this was the approach. It does still seem a little fragile.
>
>> 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.
>
>Is this to occur without RTEMS restarting ?
>
>Where is the code to manage this located and what happens with the heap.
>
>> This mechanism need not be universally. It only for this
>> project now.
>
>Understood.
>
>>
>>>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.
>>
>
>Please remember there is another package which is a host linker to be 
>uploaded. It is a C++ application with classes to manage some of what I 
>suspect you are attempting to do. It is a work in progress and I wish to 
>change some parts.
>
>>
>>>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.
>
>I would not. Any shared code with RTEMS requires -PIC code as per Linux.
>
>Chris
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20110926/5c9105d7/attachment.html>