Consider integrating Qualcomm's musl port for Hexagon

[alexrp]

glibc does not have a Hexagon port, nor does upstream musl. However, Qualcomm maintain a musl port at https://github.com/quic/musl which is used in their Hexagon toolchain.

This port is based on musl 1.2.2 (2021) so it's fairly recent. Judging by the commit history, it also doesn't change that frequently. I think it should be feasible to apply the Hexagon bits on top of musl 1.2.5. We wouldn't need to sync with Qualcomm's fork much due to the low frequency of commits.

[alexrp]

FWIW, there have been multiple attempts to upstream this port from 2020 through 2023, with the latest being in late 2023. From what I can tell reading all the mailing list threads, all(?) issues with the port have been addressed and it's just a question of getting a final review done now. So hopefully we wouldn't have to carry this patch for too long.

[andrewrk]

Alternatively, do the code in Zig instead. Related:

• provide common implementations where applicable for libc functions #2879

The end-game here is to have no .c files for musl, glibc, wasi-libc, or mingw-w64, and be able to compile them with an LLVM-less zig compiler.

[andrewrk]

Some triaging guidance:

• "zig cc" has more to do with the CLI parsing, not really applicable here
• Making a decision on this proposal does not block the 0.14.0 release, in fact it does not block any release, so the best milestone is "unplanned". The implication of assigning the 0.14.0 milestone is that we the zig project are planning to make a decision on the proposal before 0.14.0 is released.

[alexrp]

Alternatively, do the code in Zig instead.

This could work for some of the arch-specific routines introduced in the port for sure. Stuff like setjmp/longjmp, __restore, __clone, etc. Probably a good opportunity to start doing this too, since Hexagon is a relatively new musl port.

But we would still need to carry a patch with at least some of the arch bits: Stuff like the syscall list, struct stat and other types, atomics, TLS definitions, etc. The rest of musl needs those to actually compile, and replacing musl in its entirety seems like it has to be approached incrementally to be practical.