Reimplement crt0 code in Zig for vendored libcs

[alexrp]

SLoC for crt0 code in some of the libcs we vendor:

• FreeBSD libc: 825
• MinGW-w64: 524
• musl: 321
• NetBSD libc: 467
• wasi-libc: 56

(glibc is a bit harder to quantify because its organization is incredibly horrible, which results in us having a bunch of probably unnecessary code in lib/libc/glibc. I would be surprised if it's actually more than 2-3k lines of necessary crt0 code after pruning.)

This is really not a lot of code, so rewriting it in Zig would make a lot of sense, and would make progress towards #16270.

A secondary benefit would be finding any areas of the language that make writing this sort of code harder than it should be. In that regard, I can list these upfront:

• We need a way to export variables with "common" (i.e. __attribute__((common))) semantics. @jacobly0 suggested modeling this with @extern and a new std.builtin.GlobalLinkage.common tag. A separate proposal needs to be typed up for this.
• Almost every crt0 needs constructors/destructors in order to satisfy the Itanium C++ ABI - see Program coredump on exit when dlclose a dynamic loaded library which has atexit function calls #17908. While it's technically possible to emit these in Zig today, Proposal: Ability to append functions to .init_array/.fini_array #23574 would make doing so nicer and less error-prone.

[rootbeer]

Once re-written in Zig, how does the Zig crt0 code keep up with changes in the original libraries? Do Zig maintainers just need to look through the diffs in the source C library for changes that should get reflected in the Zig code? Seems fragile to me, but maybe the crt0 code doesn't change very much?

[alexrp]

Once re-written in Zig, how does the Zig crt0 code keep up with changes in the original libraries? Do Zig maintainers just need to look through the diffs in the source C library for changes that should get reflected in the Zig code?

That's right.

Seems fragile to me, but maybe the crt0 code doesn't change very much?

I don't think so:

• We can just add a step to the wiki page along the lines of "do a diff between the current and previous release's startup code".
• You already have to do some manual checks anyway because update_glibc.zig, update_freebsd_libc.zig, etc only update existing files, not new files.
• And yeah, the startup ABI does not change very often at all. For glibc, I think that's happened exactly once in all the versions we support targeting, as an example.