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

[Chris Johns]

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