2

From some time I struggle with the dynamically loaded object into process memory. How it exactly works? I found a lot of materials telling that shared objects shares the same code and has only on copy in the memory. What makes me confused is that processes loads the same library under different addresses what is visible with ldd.

ldd /bin/ls

...

libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ffff7d71000)

...

ldd /bin/cat ...

libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ffff7db5000)

...

On above, it is visible that the same library is loaded under different process addresses.

For that moment I do not understand if functions from external shared libraries are loaded to the particular process memory or just make a call to the shared memory? What I recall is that GOT tables contains addresses to the shared memory which are fulfilled during dynamic linking process, but what is the purpose of loading shared library under specified memory region visible in relocation tables?

I guess that I lack something important but do not know what

1 Answer 1

2

There are two things at work here that might be making it look a bit tricky:

  1. virtual memory - see e.g. articles at Wikipedia for a refresher of the concepts of virtual memory or page table.

  2. address space randomization (or ASLR)

When a library is to be loaded (for a new process or dynamically say via dlopen()), the dynamic linker/loader (ld-linux.so) decides where to place it (so that it can update the information from GOT with the actual values). One part of that process is finding out where to put the library text in the context of all other memory regions (application text, data, other requested libraries, stack, ...) and the other is making the addresses at least a little bit unpredictable (ASLR).

That is, why for different binaries the addresses differ (memory layouts are different), and why they might also differ for consecutive invocations (ASLR).

As for sharing the library text among several applications, that is where virtual memory comes into play - the library is loaded only once in physical memory, yet it is mapped to virtual address spaces of several processes (at different addresses).

As a closing remark, this mode of operation is not necessarily the only one - there are various strategies of handling shared libraries.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.