RTEMS Run-time Linker vs Linux dynamic linking with shared library.

[Thomas Kim]

Dear Chris,

Your comment is very useful for me.

Thanks you.

Best Regards.

2014-11-03 19:45 GMT+09:00 Chris Johns <chrisj at rtems.org>:

> On 3/11/2014 9:00 pm, Thomas Kim wrote:
>
>> Dear Sir,
>>
>> I checked that RTEMS runtime linker was updated on main tree.
>>
>> I would like to know something before testing RTEMS run-time linker.
>>
>>
> Thank you for the question.
>
>  I am guessing that RTEMS run-time linker is different with linux dynamic
>> linking with shared library(*.so.*).
>>
>
> RTEMS does not follow the ELF method of supporting shared libraries you
> find in Linux.
>
>
>> I hope that RTEMS run-time linker is same concept with Linux dynamic
>> linking with shared library.
>>
>>
> The libdl code in RTEMS loads code at runtime so in that sense it is the
> same. It however locates relocatable code performing fix ups on code as it
> is loaded which produces the same result as if you had statically linked
> it. This is some documentation on the topic:
>
> http://www.rtems.org/ftp/pub/rtems/people/chrisj/rtl/rtems-rtl.html
> http://www.rtems.org/ftp/pub/rtems/people/chrisj/rtl/rtems-linker/
>
> The shared library model provided in operating systems such as FreeBSD and
> Linux is as much about sharing code in the physical memory between a number
> of processes as it is about dynamic loading and the ability to share the
> code is very important. RTEMS is a single address space, single process
> system and so there is no need to share code. The performance of the loaded
> code should match the performance you would get if you had statically
> linked it, ie deterministic behaviour, and that is what we have achieved.
> If the code runs slow, even a small amount users would end up just
> statically linking. The other side of this is the need to perform some
> specific link type processing on the host to manage the process of creating
> loadable code plus we need to have the symbols on the target to link and
> this uses memory.
>
> I hope this helps.
>
> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20141104/8aae3433/attachment-0002.html>