The System V ABI for both x86 and x86_64 requires that the stack pointer
is 16-byte aligned on entry. Previously we did not align the stack
pointer properly.
As far as "main" was concerned the stack alignment was correct even
without this patch due to how the C++ _start function and the kernel
interacted, i.e. the kernel misaligned the stack as far as the ABI
was concerned but that misalignment (read: it was properly aligned for
a regular function call - but misaligned in terms of what the ABI
dictates) was actually expected by our _start function.
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
GCC will insert various calls to pthread functions when compiling
C++ code with static initializers, even when the user doesn't link
their program against libpthread explicitly.
This is used to make static initializers thread-safe, e.g. when
building a library that does not itself use thread functionality
and thus does not link against libpthread - but is intended to
be used with other code that does use libpthread explicitly.
This makes these symbols available in libc.
The dynamic linker is already taking care of this for us. Now
that crt0 is statically linked into each executable and shared
library this breaks things because initializers are invoked twice.
Before this PR this didn't crash because crt0 and its _start()
function was contained in LibC and thus only LibC's initializers were
invoked several times which wasn't as much of a problem because
these initializers didn't have any side effects (such as malloc/free).
However, user programs are more likely to have constructors with side
effects, e.g.:
std::string g_test("hello!");
This would allocate memory when the constructor is invoked. When it is
invoked again the original allocation would be leaked and another copy
of the string would get allocated. Worse still, when the destructors are
invoked twice the memory would get free'd twice which would likely
crash the program.
