Dynamic link library in C
I have some questions about dynamic link libraries in C.
My textbooks uses a picture to illustrate how DLL works,
and it seems that some relocation and symbol table information of
libc.so are copied (the arrow is attached to their side), but whenever the assembler encounters a reference to an object whose ultimate location is unknown, it generates a relocation entry that tells the linker how to modify the reference when it merges the object file into an executable. For libc.so, everything is known(it has all definitions), so there shouldn't be any relocation entry for libc.so, isn't it
Q2. My textbook says that:
"a single copy of the .text section of a shared library in memory can be shared by different running processes",
Let's say I have a program that uses
printf. Does the
.text section of
printf stay in RAM forever or does it get evicted from RAM when the first program finishes, and get loaded in RAM when a second process uses
If the latter is the case, isn't that very inefficient that the
.text section of
printf gets evicted and loaded in RAM many many times since we have multiple processes that could be running in the background?
Q1: The diagram you provided seems correct to me. It is
main2that is being constructed; the relocation and symbol table information of
libc.soare being copied in so that the final executable can make use of them. From the perspective of
main2, functions, constants, etc. from
libvectorare being added, so I agree with your textbook that the relocation and symbol table information of
libc.soare being copied.
Q2: You present only the two extremes: "stay in RAM forever" or "evicted from RAM when the first program finished". Almost certainly, the sharable portions of libraries will stay in RAM as long as some recently-running process has made use of them. A typical strategy an OS will use is an LRU algorithm to evict 'unused' things from RAM, but only when it wants to load more into RAM than there is room for. So, on a lightly used machine, nearly everything might hang around in RAM for quite a long time; but on a very heavily overtaxed machine, the OS will be constantly discarding things from RAM that it will need again very soon. But even then, some things are used so frequently, they are unlikely to ever meet the LRU threshold, so you might have some certain things in RAM for a long time, even if most things are being evicted.
Q1 follow-up: In answer to your question in your comment: correct: there is nothing in
main2.cto define functions found in
libc. It is because of this that the linker needs to copy in the relocation and symbol table information for
libc.so, so that when
libc.soalso gets loaded.
In more detail:
printf()might be called from
printf()is declared in
stdio.hand defined in e.g.
printf.c and compiled into
main2.ccan be compiled because the compiler can see the signature for
stdio.h), but to build
main2(the executable), the code already compiled in
libc.soneeds to be linked with
main2.o(the intermediate object file).
lddoes this by copying in the references that cause execution of
main2to dynamically load
 Compilers will differ on how standard library functions are defined;
gcchas a file
printf()(and it's actually a pass-through to
vfprintf()); other compilers might do it differently -- but the whole point of libraries is that you don't ever need to look at the definition of
printf()and other library functions; you only need the declaration from the appropriate
.hfile in order to know how to call it in your own
 Or, if you build a statically linked executable, the code -- not just the symbol table -- is copied from the library file into the executable being built, and that executable can be run even on a machine without the
.sofiles present. Whether or not dynamic linking or static linking is better for building a given executable depends on several factors.