RTEMS Run-time Linker vs Linux dynamic linking with shared library.
thomas73.kim at gmail.com
Tue Nov 4 01:17:35 UTC 2014
Your comment is very useful for me.
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:
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users