Separate L4Re code, add aarch64 and enable tests

[farao]

Description

The L4Re code was previously attached to the Linux code which was not correct in many ways. This commit separates the L4Re code and enables the libc-tests and includes the fixes for the failing tests. Aarch64 is added as a second supported architecture (more to come).

Sources

L4Re-adapted version of uclibc: https://github.com/kernkonzept/l4re-core/tree/master/uclibc/lib.

Checklist

• Relevant tests in libc-test/semver have been updated
• No placeholder or unstable values like *LAST or *MAX are
  included (see #3131)
• Tested locally (cd libc-test && cargo test --target mytarget);
  especially relevant for platforms that may not be checked in CI

[rustbot]

r? @tgross35

rustbot has assigned @tgross35.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

Some changes occurred in solarish module

cc @jclulow, @pfmooney

[farao]

Some changes occurred in solarish module

cc @jclulow, @pfmooney

Sorry, I accidentally submitted a format change. I fixed it, there's no change to the solarish module anymore now.

[farao]

edit: resolved (see below)

@tgross35 The nightly freebsd fails are not due to this change. But I don't understand why the style check of src/l4re/mod.rs fails. I executed cargo fmt before submitting and

rustfmt --config-path rustfmt.toml src/l4re/mod.rs --check

is locally successful for me (with rustfmt 1.8.0-nightly (2fa8b11f09 2025-04-06) from current rust nightly in rustup).

Any idea why?

[farao]

@tgross35 The nightly freebsd fails are not due to this change. But I don't understand why the style check of src/l4re/mod.rs fails. I executed cargo fmt before submitting and

rustfmt --config-path rustfmt.toml src/l4re/mod.rs --check

is locally successful for me (with rustfmt 1.8.0-nightly (2fa8b11f09 2025-04-06) from current rust nightly in rustup).

Any idea why?

This was because I did not run the style check with the extra_traits feature. I fixed that.

However it now shows that

sort -C libc-test/semver/l4re.txt

fails but also that succeeds for me locally and I sorted the file via sort before checking it in.

Update: sort apparently sorts differently depending on LC_ALL, I sorted again with LC_ALL=C

[tgross35]

Thanks for this PR, I'll try to take a look soon. We recently decided to do some reorganization that would flip the module order around, so e.g. uclibc is a top-level module and its code can be reused across both Linux and L4re. Are you okay holding off for a couple of weeks on this? If we can get that in progress first, it should eliminate a lot of the duplicated definitions here.

[farao]

Good idea to turn the order around! The thing is that much of the L4Re support was incorrect while still attached to the linux code path and the change also removes unnecessary l4re exceptions from the unix, linux_like and linux mods. So I think, the refactoring (turning the order around) would be easier if we applied this change first. I also can help with the refactoring once you want to start with it.

Additionally, since we would like to bring aarch64 support for L4Re into the main rust repo (to be able to build for this arch) and the support in this crate is a precondition, my preference would be to have it merged before the refactoring.

Would that be ok for you?

[farao]

@tgross35 any thoughts about this? do you think we can get the aarch64 support into the next libc release?

[tgross35]

Sorry this has taken so long; there is a massive diff here and it has taken me a while to get through it.

It seems like a lot of this code comes verbatim from linux/mod.rs; there is still config for musl, arm, 32-bit x86, and other things that aren't relevant for our l4re targets. This would require significant cleanup and we would still have nearly identical code in two different places, so unfortunately I don't think the approach here is the best way forward.

The refactoring I mentioned above is still a little while off so we shouldn't wait for that. Instead, I think we could work with something like this:

• Move this PR's src/l4re/mod.rs to linux_like/l4re/{mod.rs, ...}
• Move the code you need from linux_like/linux/mod.rs to linux_like/shared.rs
• Import everything from shared for both l4re and linux
• #[cfg(...)] out anything relevant in shared (or the unix parent modules) that is on linux but not l4re

The last step is going to be the trickiest since we don't do this anywhere yet, but will need a pattern like this in the near future anyway. The style check might yell at you but you can disregard it for now (will need to be updated before this merges).

Similarly,, libc-test/build.rs should use test_linux and gate relevant bits behind if l4re, rather than duplicating most of that function.