Dynamic linking library

Dynamic linking library

[ratheesh k]

Suppose there are two executable elf . say A, B . And these two are
using  libctest.so.
When A is executed  libctest.so is loaded into RAM and linear address
is  correctly mapped.

If we execute program B after A ,  will library will be loaded again ?
else, how OS know that libctest is already loaded into physical page ?
(so it can  map linear address to it )

-Ratheesh

Re: Dynamic linking library

[Michal Nazarewicz]

On Thu, 20 Jan 2011 12:37:25 +0100, ratheesh k <ratheesh.ksz@gmail.com>  
wrote:

> Suppose there are two executable elf . say A, B . And these two are
> using  libctest.so.
> When A is executed  libctest.so is loaded into RAM and linear address
> is  correctly mapped.
>
> If we execute program B after A ,  will library will be loaded again ?

When A is executed dynamic loader opens the library and then mmap(2)s it
into virtual address space.

When B is executed, from user space (ie. dynamic loader) point of view the
very same thing happens: dynamic loader opens the library and mmap(2)s it
into virtual address space.

What happens behind the scene, is that when the libctest.so is opened, file
system figures out it's inode and then opens file with given inode number.
The first time this is done, system creates all bunch of structures for
the file, however, the second time, system sees that a file with given  
inode
number is already opened so some data can be shared between the two  
instances.

Re: Dynamic linking library

[Glynn Clements]

ratheesh k wrote:

> Suppose there are two executable elf . say A, B . And these two are
> using  libctest.so.
> When A is executed  libctest.so is loaded into RAM

No, it is *mapped* into the process' address space (virtual memory). 
Data is loaded into physical RAM on demand by the kernel.

> and linear address is correctly mapped.
> 
> If we execute program B after A ,  will library will be loaded again ?

It will be mapped into B's address space.

> else, how OS know that libctest is already loaded into physical page ?
> (so it can  map linear address to it )

Mapping a file into a process' address space sets up structures within
the kernel recording the fact that specific pages of the process'
address space correspond to specific blocks of a specific device.

Initially, the MMU will consider those pages as unmapped, so accessing
those addresses will cause the CPU to generate an exception (page
fault). The kernel handles the exception by ensuring that the
appropriate disk block is loaded into physical RAM, updating the MMU
so that the virtual memory page is mapped to the appropriate physical
memory page, then restarting the instruction.

When cached blocks are discarded from physical RAM, any the MMU
mappings are removed so that a subsequent access will raise an
exception.

-- 
Glynn Clements <glynn@gclements.plus.com>