Chrome is (mostly) shipped as a single executable that knows how to run as all the interesting sorts of processes we use.
Here's an overview of how that works.
On Windows we build the bulk of Chrome as a DLL. (XXX: why?) wWinMain loads chrome.dll, does some other random stuff (XXX: why?) and calls ChromeMain in the DLL.
Mac is also packaged as a framework and an executable, but they're linked together: main() calls ChromeMain() directly. There is also a second entry point, in chrome_main_app_mode_mac.mm, for app mode shortcuts: "On Mac, one can't make shortcuts with command-line arguments. Instead, we produce small app bundles which locate the Chromium framework and load it, passing the appropriate data." This executable also calls ChromeMain().
On Linux due to the sandbox we launch subprocesses by repeatedly forking from a helper process. This means that new subprocesses don't enter through main() again, but instead resume from clones in the middle of startup. The initial launch of the helper process still executes the normal startup path, so any initialization that happens in ChromeMain() will have been run for all subprocesses but they will all share the same initialization.