Fix for kernel 4.2: don't use 64 bits syscalls/types

[quic-mathbern]

The currently Linux kernel version supported by qemu is based on upstream kernel 4.2 1.

However, the 64 bits syscalls from musl are not implemented by Hexagon kernel 4.2. And the time_t type is now 64 bits for all archs on musl (not only the 64 bits archs), so we also need to force our own type size here for kernel 4.2.

Furthermore, we need to refrain from using faccessat2, as this was only added at kernel 5.8.

[androm3da]

This provides compatibility with 4.2 and doesn't introduce problems when building with/for 6.x?

Is this statement true? The linux userspace programs built with this new musl will work well when using qemu-hexagon on a modern x86_64 kernel.

If it's not the case maybe we want an ifdef in this file? Or maybe we want to create a separate target branch for this PR?

[androm3da]

This provides compatibility with 4.2 and doesn't introduce problems when building with/for 6.x?

Is this statement true? The linux userspace programs built with this new musl will work well when using qemu-hexagon on a modern x86_64 kernel.

AFAICT this is the case - I ran some tests this weekend with this musl change and it seemed to work well.

[alexrp]

Sorry to hijack this PR for a question, but I'm confused and it seems relevant: Is the implication here that qemu-hexagon from QEMU master supports a different time ABI than Linux master? If so, how should we deal with that in Zig? FWIW, we recently made the decision that Zig will not support 32-bit time on Linux going forward, even if that means we have to bump some of our baseline kernel/libc version requirements.

[androm3da]

Sorry to hijack this PR for a question, but I'm confused and it seems relevant: Is the implication here that qemu-hexagon from QEMU master supports a different time ABI than Linux master?

No: thankfully, QEMU's behavior matches the kernel's.

If so, how should we deal with that in Zig? FWIW, we recently made the decision that Zig will not support 32-bit time on Linux going forward, even if that means we have to bump some of our baseline kernel/libc version requirements.

We have an effort ongoing to boot linux in system emulation mode. We have yet to publish all of the bits needed for this, unfortunately. And ignoring that issue, the linux kernel that we have available booting in QEMU is very old (v4.2), from before this change to the kernel 32/64-bit time changes.

Having this bootable hexagon kernel available to the community would be nice, because among other things it would likely make it easier to upstream musl because then musl devs can see how musl behaves with a real hexagon linux kernel (and not a hexagon kernel emulated by the x86_64 one). With this PR, we were trying to make a musl that solves this problem but IIRC this PR was not intended/designed to be compatible with both 64-bit and 32-bit time. So it can't be applied as-is.

I think the solution for our time woes is either to rebase our old kernel changes on newer releases (and once that works, land those changes upstream). But we just aren't there yet.