The Journey Before main()

Summary

A while back, I worked on a RISC-V-based userspace simulator for fun. In doing so, taught myself a lot more than I wanted to know about what happens in-between when the Kernel is asked to run a program, and when the first line of our program’s main function is actually executed. Here’s a summary of that rabbit hole. In the beginning… First question: When is the OS kernel actually asked to run any program? The answer, at least on Linux, is the execve system call (“syscall”). Let’s take a quick look at that: int execve(const char *filename, char *const argv[], char *const envp[]); This is actually quite straightforward! We pass the name of the exectuable file, a list of arguments, and a list of environment variables. This signals to the kernel where, and how, to start loading the program. Many programming languages provide an interface to execute commands that eventually call execve under the hood. For example, in Rust, we have: use std::process::Command; Command::new("ls").arg("-l").spawn(); In these higher-level wrappers, the language’s standard library often handles translation of the command name to a full path, acting similarly to how a shell would resolve the command via the PATH environment variable. The kernel itself, however, expects a proper path to an executable file. A note on interpreters: If the executable file starts with a shebang (#!), the kernel will use the shebang-specified interpreter to run the program. For example, #!/usr/bin/python3 will run the program using the Python interpreter, #!/bin/bash will run the program using the Bash shell, etc. ELF What does an executable file look like? On Linux, it’s ELF, which the kernel knows how to parse. Other operating systems have different formats (e.g. Mach-O on MacOS, PE on Windows), but ELF is the most common format on Linux. I won’t go into too much detail here, to keep things brief, but ELF files have grown out of the original a.out format, and are expressive enough to support pretty much every progr...