This applies to stage2 where we make use of the cache system to work
out if we need to relink objects when performing incremental updates.
When the process is restarted however, while in principle the idea is
to carry on where we left off by reparsing the prelinked binary from
file, the required machinery is not there yet, and therefore we always
fully relink upon restart.
This is particularly relevant for x86_64 and C++ when relocating
StaticInit sections containing static initializers machine code.
Then, in case of SIGNED_X relocations, it is necessary to have the
full image of the VM address layout of the sections in the object
file as this is how the addend needs to be adjusted for non-extern
relocations.
Also, calculate non-extern, section offset based addends for SIGNED
and UNSIGNED relocations on x86_64 upfront as an offset wrt to the
target symbol representing position of the section/atom within the
final artifact.
Otherwise, Apple's tooling goes mental and reports that the executable
is malformed/fails strict validation. We absolutely have to get it
right to support tools such `codesign` which are required to
successfully launch an app on an iOS device for instance. When Zig
matures enough so that we can ditch any Apple tooling and still be
able to successfully codesign for iOS and other, we can revisit this
area. Until then however, we are stuck in having to rewrite the LINKEDIT
segment at every update run of the self-hosted.
FYI, the strict layout for the MachO binary apparently is (please,
read this with a pinch of salt as this is inferred by me):
* __TEXT segment
* __DATA_CONST segment
* __DATA segment
* __LINKEDIT segment
* dyld info (rebase, bind, weak bind, lazy bind, export)
* symbol table
* dynamic symbol table
* string table
* code signature (if expected)
Instead of checking for stage1 at every callsite, move the logic
inside `allocateAtom`. This is fine since this logic will disappear
anyhow once I add expanding and shifting segments and sections.
This commit makes it possible to combine self-hosted with a pre-compiled
C object file, e.g.:
```
zig-out/bin/zig build-exe hello.zig add.o
```
where `add.o` is a pre-compiled C object file.
This way, we will conform to the standard practice of setting the
offset within the section header to the beginning of the file and
we will be able to track the location of the section in the file
for incremental updates.
