bytecodealliance
Be
- Configure
rustixto use thelinux_rawbackend onarmeb-unknown-linux-gnueabiandaarch64_be-unknown-linux-gnutargets. (Both of these are tier 3 rust platforms and hence no public binaries are provided). - Since
rustixusestempfilefor its unit test, which in turn usesrustixas a dependency we have a cyclic dependency. Change theCargo.tomlso that the version ofrustixused to satisfy thistempfiledependency is the working copy.
Seems the freebsd test failure issue is unrelated? This workflow appears to have run successfully.
https://github.com/bytecodealliance/rustix/actions/runs/15474936766
A few of the other commits also adress issues caused by the release of new crates which require a version of rust higher than the MSRV.
Lastly, there is a commit to fix an issue whereby constants guarded by the stdio feature are used within the tests of the fs feature although there is no dependency between those features.
@bjorn3 Thanks for the feedback. Just let me know how best to proceed and I'm happy to make any changes.
How much testing have you done with the linux_raw backend on these targets? There are some places in the Linux syscall ABI which are sensitive to endianness, such as when 32-bit values are split into two halves, so it'd be good to have some assurance that this code is working before enabling it on these targets.
When I ran the tests locally, there were a handful of failures. But ideally I'd like to add CI for these targets, the only thing is that it requires:
- An
armbe-linux-gnueabi-andaarch64_be-linux-gnu-cross compiler (since we would need a linker) and neither the standard linux distros, nor ARM themselves provide a pre-built one ready to use. - Either:
- A build of
qemu-systemsupporting the relevant targets with accompanyinginitrdandkernel. - A build of
qemu-usersupporting the relevant targets.
- A build of
I have already made most of these for some other projects, but wondered what if anything would be the best approach.
- There are containers with cross-compilers as part of
frida'sdocker-imagesrepo for armbe and aarch64_be. These could either be used as is, or duplicated into the repo. - There is also a container with
qemu-system,kernelandinitrdhere. Again this could be either used as is, or duplicated. The workflow for running this sort of setup is a little clunky and would look a bit like this. - Building
qemufrom source to supportqemu-armbeandqemu-aarch64_beisn't too hard, so again a container could be made for that, or it could be built and installed as part of a CI job (though likely some form of caching would be useful to speed up this job).
The consideration is in deciding whether to use resources from other projects or whether to replicate the same functionality to give more control. Then of course there is the additional cost in terms of resources and time for the CI.
I'm happy to go away and start working on a solution if you think it would be beneficial, but would be grateful if you have some advice on which direction to take.
I don't want to enable linux_raw on architectures that it hasn't been tested on, and I'm not eager to maintain new complex testing configurations.
Would it make sense to enable linux_raw for these architectures under the RUSTFLAGS=--cfg=rustix_use_experimental_asm flag, similar to what powerpc, s390x, and mips use? That way, end users can explicitly opt into it if they wish to. See the rustix_use_experimental_asm code in build.rs for details.
Sure. That makes sense. They aren't the most common of architectures to be fair. I'll introduce a new flag, something like "use_linux_raw_on_experimental_arch".
I'm curious why you introduced a new rustix_use_untested_linux_raw flag, rather than reusing the existing rustix_use_experimental_asm flag.
It seemed the reasons for having the flags differed although the result was the same (defaulting to the libc bindings). In the case of PPC, it was because rust hasn't stabilised inline asm. In the case of big endian arm it was because the overhead of adding sufficient CI was to great considering its not a very popular architecture. Happy to change if you'd rather?