Understand and Implement Dynamic Linking

Late Binding with Shared Libraries

Dynamic linking loads .so / .dylib / .dll at runtime. PLT and GOT on x86-64 redirect external calls through stubs resolved on first call. ld.so maps libraries and performs relocations. Most Linux programs dynamically link libc.

PLT/GOT Mechanism

First call printf jumps through PLT stub to GOT entry pointing at resolver. Resolver patches GOT with real printf address; later calls go direct.

cCopy
Loading…

• -fPIC generates position-independent code
• -shared builds shared objects
• dlopen loads libraries at runtime manually
• Symbol visibility: default, hidden, protected

Connecting to real compilers

Production compilers embed this step inside a longer pipeline. GCC flows through cpp, cc1, assembly, and ld; Clang uses the driver, Sema, LLVM IR passes, and a target backend. LLVM bitcode, JVM bytecode, and WASM are other familiar IRs at the same layer. The exercise isolates one pass so you can test it alone before chaining it to the next stage.

Why for this exercise

You will understand and implement dynamic linking concepts. This exercise asks you to model GOT/PLT indirection and runtime symbol resolution for external function calls.