The Loader

The path from execve to main is a specific sequence with several places to fail, and knowing it turns a class of opaque startup failures into ordinary diagnosis.

The kernel reads the executable's headers, checks the format, and creates a fresh address space. It maps the loadable segments at their specified addresses with their specified permissions — typically a read-execute segment for code, a read-only one for constants, and a read-write one for data, with .bss mapped as zero-filled anonymous memory beyond the file-backed part. It sets up the stack with the arguments, the environment and the auxiliary vector.

Then, crucially, it does not jump to the program. If the image names an interpreter — which every dynamically linked executable does, in its PT_INTERP header — the kernel maps that too and transfers control *there*. The dynamic loader is itself a program, statically linked and self-relocating, and it now runs in the address space of the process it is preparing.

The loader reads the needed libraries, finds and maps each one recursively, builds the search scope, applies relocations, resolves data symbols, and runs the initializers of each object in dependency order — deepest first, so a library's dependencies are initialised before it is. Only then does it jump to the executable's entry point, which is _start in the C runtime, which sets up a little more state and calls main.

The entry point recorded in a typical C or C++ executable is _start, supplied by the C runtime startup object (crt1.o and friends), and it is doing real work before main. It aligns the stack as the ABI requires, extracts argc, argv and envp from where the kernel left them, initialises thread-local storage, calls the C library's initialisation, runs any remaining constructors, registers the exit handling, and then calls main — and calls exit with whatever main returns.

Before even that, every shared object's initializers have run. In C++ this includes the constructors of every global and static object with dynamic initialization, across the executable and every library. In C it includes anything marked with the constructor attribute. These run in an order determined by dependency relationships between objects and, within one object, by link order — which is under-specified enough that depending on it is a well-known way to produce a bug that appears when someone adds an unrelated library.

This is why a program can fail before main in ways that look impossible. A global object's constructor throws and the process terminates with no stack trace anyone recognises. Two globals in different translation units depend on each other and one is used before construction — the static initialization order fiasco, whose standard remedy is the function-local static, constructed on first use rather than at load. And on some platforms an initializer that calls into a library whose own initializers have not run yet will do something arbitrary.

Loading is mapping, not reading. The loader calls mmap on the executable file and each library, so the pages are file-backed and demand-paged: nothing is read from disk until an instruction touches a page and takes a fault. That is why a large binary starts quickly and why start-up cost is dominated by page faults on the pages actually touched rather than by file size.

Because the mappings are file-backed and read-only for code, the same physical pages back every process running the same binary or library. This is the sharing that [[dynamic-linking]] is bought for, and it is a property of the mapping rather than of anything the loader does explicitly. Writable data is mapped copy-on-write: shared until written, private after.

.bss has no file content, so it is mapped as anonymous zero-filled memory. And relocations complicate the picture slightly: applying a relocation writes to a page, so any page containing relocations becomes private to the process. This is why the number of load-time relocations is a real memory cost as well as a time cost, and why compressed relocation formats and prelinking were both attempts to reduce it.

Each stage of the sequence has a characteristic failure with a characteristic message, and the messages are unusually informative once you know which stage produced them.

The kernel refuses the image: exec format error, meaning the architecture or the format is wrong — a cross-compiled binary on the wrong machine, or a script without a valid shebang. The interpreter is missing: No such file or directory on a file that visibly exists, which is the kernel reporting that the *interpreter* named in PT_INTERP was not found — the single most confusing message in this whole area, and it is why a glibc binary run on a musl-only system says the file does not exist. A library is missing: cannot open shared object file. A symbol is missing or version-mismatched: undefined symbol or version GLIBC_2.34 not found. And finally an initializer crashes, which produces an ordinary fault with a stack that bottoms out in the loader.

The tooling maps onto the stages directly. file and readelf -h answer the format question. readelf -l | grep interpreter shows which interpreter is demanded. ldd and LD_DEBUG=libs cover library finding. LD_DEBUG=bindings covers symbol resolution. And a debugger with a breakpoint before main — gdb, break main, then bt from a crash — covers initializers.