Exercises — Dynamic - shared libraries — .so - .dll, dynamic linking, PIC

• Shared / dynamic on Linux: ==.so== (shared object).
• Static on Linux: ==.a== (archive).
• For the record: Windows uses .dll (dynamic) and .lib (static, or an import stub). The mental picture: .so = one file loaded at run time and shared; .a = a bag of .o files copied into the executable at link time — see Static libraries — .a .lib.

• Data table of real addresses: GOT (Global Offset Table). Writable, so the loader can patch it per process.
• Stub table for lazy function resolution: PLT (Procedure Linkage Table). Rhyme to remember: GOT stores Gone-and-fetched addresses; PLT is the Polite doorman that fetches them the first time.

• PIC: ==-fPIC==.
• Emit shared object: ==-shared==. Typical build: gcc -fPIC -c foo.c -o foo.o then gcc -shared foo.o -o libfoo.so.

First, the unit convention we use throughout this problem: $1\text{MB}=2^{10}\text{KB}=1024\text{KB}$ (binary/base-2 kibi units). So the code segment is $2\text{MB}=2\times 1024\text{KB}=2048\text{KB}.$ Now walk the two cases in words, then in numbers.

Dynamic: there is exactly one physical copy of the 2048 KB code, shared by all 200 processes. Each process still keeps its own private 48 KB data page (its GOT lives here — it must differ per process). So we add one code copy plus 200 data copies: ${\text{RAM}}_{\text{dyn}}=\underset{\text{one shared code copy}}{\underbrace{2048}}+\underset{\text{one data copy each}}{\underbrace{200\times 48}}=2048+9600=11648\text{KB}.$

Static: nothing is shared — every process carries its own full code and its own data: ${\text{RAM}}_{\text{stat}}=200\times (2048+48)=200\times 2096=419200\text{KB}.$

Savings: $419200-11648=407552\text{KB}=\frac{407552}{1024}\text{MB}\approx 398\text{MB}.$ The single shared code copy is the whole point — see Virtual Memory & mmap for how one physical page maps into many processes. Exercise L3.1 (figure s01) draws exactly this "one shared code page, many private GOTs" picture.

Lazy binding resolves a symbol only on its first call. Uncalled functions are never resolved.

• Resolved: 12.
• Fraction: $12/500=0.024=2.4\%$. If instead you forced eager binding (e.g. LD_BIND_NOW=1), all 500 would resolve at startup — $500/500=100\%$ — most of it wasted work. That is exactly why lazy is the default.

Before plugging in numbers, understand the two-step "why" — this is the heart of PIC and figure s02 below draws it.

Step 1 — offset → slot. The code bytes may not contain S's absolute address (that would break sharing, see L3.1). What they can safely contain is a constant distance from the current instruction (the PC) to S's GOT slot — a distance that is the same in every process because the code and its GOT are mapped as a fixed unit. So the code computes $\text{slot address}=\text{PC}+\text{offset}=\text{0x555555001000}+\text{0x2FE0}=\text{0x555555003FE0}.$ This only locates the mailbox; it is not yet the address of S.

Step 2 — slot → real address (dereference). The GOT slot is a pointer. The loader has already written S's true per-process address into that slot. So the code performs one memory load — a dereference — reading the value stored there: $\text{addr}(S)=\text{GOT}[S]=\left(\text{value stored at }\text{0x555555003FE0}\right)=\text{0x7FFFF7A50120}.$

Why two steps and not one? Because the location of the mailbox is fixed (offset, safe in code) but the letter inside it is per-process (absolute address, kept in writable data). Splitting them is exactly what lets the code bytes stay identical across processes while the address still varies. No absolute address is baked into the code — only the relative offset 0x2FE0 is.

1. Goal: N processes share one physical copy of the library's instruction bytes (that's the RAM win).
2. A shared physical page can be mapped at different virtual addresses in different processes, but its bytes are byte-for-byte identical for all sharers.
3. The real location of an external symbol (e.g. printf) differs per process (different mappings, ASLR).
4. If those differing addresses lived in the code bytes, the bytes couldn't be identical → sharing breaks.
5. Therefore per-process addresses must live in a per-process data page (the GOT), and the code reaches them indirectly, via PC-relative offsets. That chain is PIC. It is not an arbitrary flag — it is forced by "share the code bytes." Cross-check with ASLR & Security for why (3) is even more true today.

The figure below (s01) draws this argument. A single blue box in the middle is the shared, read-only code page — its bytes are identical for both processes. Below it sit two white boxes, Process A and Process B, each holding its own yellow GOT slot for printf: A stores 0x7f.., B stores 0x7e.. — different absolute addresses. The green arrows from the code page to each process carry the same PC-relative offset, yet land on different addresses because each process reads its own GOT. The red caption underlines the moral: the differing absolute address lives in the GOT (data), never in the code.

There are two different searches at two different times:

• Link time (-lfoo): the linker only checks that each needed symbol exists inside libfoo.so and records the dependency name. That recorded name is stored in the ELF file as a DT_NEEDED entry — literally a list, inside the binary, of "library filenames I will need at run time" (DT_NEEDED is just the ELF tag for one such "needed library" record; see ELF and PE file formats). The linker does not copy the code and does not care where the file will physically be at run time. See The Linker — symbol resolution & relocation.
• Run time: ld-linux.so reads those DT_NEEDED names and must physically find each file by scanning /lib, /usr/lib, LD_LIBRARY_PATH, the binary's RPATH/RUNPATH, and the ldconfig cache. If you moved the .so, or built it in a non-standard directory and never ran ldconfig / set the search path, the symbol existed at link time but the file can't be found at load time. Link success ≠ run availability.

First call: call foo@plt jumps to foo's PLT stub. The GOT slot still points back into the PLT (to the resolver trampoline). So control goes to the dynamic linker's resolver, which looks up foo's real address, writes it into the GOT slot, and then jumps to foo. Cost = one full symbol resolution. Second call: call foo@plt again hits the stub, whose first instruction is "jump to whatever the GOT slot holds." The slot now holds foo's real address, so it jumps straight there. Cost = one indirect jump (a few nanoseconds). The PLT stub is written so it always jumps through the GOT; lazy resolution is just the trick of having the slot initially point at the resolver, then rewrite itself.

• Mechanism: run-time loading via dlopen() — you cannot link against a file that didn't exist when app was built, so ordinary -l linking is impossible. See dlopen and Plugin Architectures.
• Two calls: dlopen("png_renderer.so", RTLD_NOW) loads and links the plugin; dlsym(handle, "create_renderer") fetches the address of a known, agreed-upon symbol. (Clean up with dlclose.)
• Contract: every plugin must export a fixed, agreed symbol name with a fixed signature — e.g. a factory function Renderer* create_renderer(void). app and every plugin share only this ABI; the plugin's internal function names are irrelevant. Optionally a plugin_abi_version symbol so app can reject incompatible plugins. Why this works: dlsym is just a run-time version of the symbol resolution the linker normally does at build time — the GOT/PLT machinery already knows how to fetch addresses at run time, and dlopen exposes that to your code.

• Explicit exports/imports. ELF exports every non-static symbol by default; the PE/DLL model exports nothing unless you mark it. Add __declspec(dllexport) when building the DLL and __declspec(dllimport) when using it (usually via one macro flipped by a build define). See ELF and PE file formats.
• GOT equivalent: the IAT (Import Address Table), patched by the Windows loader — same job as the GOT (indirection slots filled with real addresses at load time).
• Base-address strategy: DLLs historically preferred a fixed preferred base and rebased (relocated) only on collision; ELF leans on PIC (Position-Independent Code) always. ASLR now forces relocation on both, so the practical gap shrinks — same problem (unknown load address), different default fix.

The pointer is stored in a writable data page and marked with a relative relocation (R_*_RELATIVE). At load time the dynamic linker computes load_base + link_time_offset and writes the real address into that data slot — exactly the same "constant code, per-process data" split as the GOT. Key point: the code page still contains only the relative offset used to reach that data slot; nothing per-process is baked into the shared instruction bytes. The per-process absolute pointer lives on a private data page. This is why a PIC .so can still have "pointers to its own strings" and remain shareable.

• Still needs -fPIC: yes, if you want it mappable at an arbitrary base. Here is the crucial insight: the reason for PIC is that the load address is unknown at compile time, not that you call outsiders. Internal function calls can use PC-relative jumps (cheap, no GOT needed). But any reference to the library's own global data whose absolute address depends on the load base still needs either PC-relative addressing or a relative relocation — otherwise those bytes would differ per process and break sharing (same argument as L3.1). Compiling -fPIC guarantees the whole image is position-independent, internal references included.
• Does the GOT do anything? Its external entries shrink toward zero, so in that sense it carries no useful symbol addresses. But the loader still allocates a small GOT that holds housekeeping slots the dynamic linker itself uses (for example a pointer back to the linker's own bookkeeping). So "no external symbols" makes the GOT nearly empty of user data, but it does not delete the GOT — the concept and a minimal table still exist. Bottom line: PIC is about the load address being unknown, not about having external calls. Even a fully self-contained library, loaded at an ASLR-randomized base, must be position-independent. See ASLR & Security for why the base is randomized at all.

1. Single self-contained deploy / "copy one file and run" — e.g. a Go/Rust CLI or a container scratch image. There's one process, no other program shares the library, and "no .so to find at run time" removes an entire class of error while loading shared libraries failures. The RAM-sharing benefit is null when only one process exists.
2. Reproducibility / air-gapped or safety-critical systems — you pin the exact library bytes into the binary so a later system update to libssl.so can't silently change behavior. Here the "update without recompiling" advantage of dynamic linking is a liability, not a feature. Both cases share a theme: the shared-library wins (RAM sharing, hot-swap updates) become irrelevant or unwanted, and static's downsides (fat binary, relink to patch) are acceptable prices. See Static libraries — .a .lib for the mechanics.

Static .a copies code in when? ::: At link time, into the executable. Dynamic .so code lands when? ::: At run time, mapped by ld-linux.so. What does PIC stand for and why does a library need it? ::: Position-Independent Code; so identical code bytes can be mapped at different virtual addresses across processes. GOT holds what, and is it writable? ::: Real per-process addresses of external symbols; yes, so the loader can patch it. First vs second call to foo() under lazy binding? ::: First resolves via the PLT resolver and writes the GOT slot; second jumps straight through the now-filled GOT slot. The two-step PIC address computation? ::: PC + offset locates the GOT slot; dereferencing that slot yields the real address of the symbol. Windows equivalent of the GOT? ::: The IAT (Import Address Table). To load a plugin unknown at compile time you use? ::: dlopen + dlsym (a run-time function pointer). What is a DT_NEEDED entry? ::: An ELF record inside a binary naming a shared library it will need at run time; the dynamic linker reads these to know what to locate.