-
Notifications
You must be signed in to change notification settings - Fork 349
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Run MIR-libstd tests for other architectures #202
Comments
I think this is blocked on rust-lang/rust#36501, because we can't build apple/windows jemalloc on linux |
Right so we want to build libstd with the system allocator, so the only code that has to be cross-compiled is Rust code. |
If rust-lang/rust#43628 goes through in its current form, we'd be all set, no more need for xargo |
However, I will soon want for miri to be tested against a libstd that also uses |
We can use lld as the linker and we inject our own jemalloc crate which doesn't do anything. |
Or we use features = ["force_alloc_system"] in xargo.toml. |
According to xargo README, that doesn't actually work, exactly due to lack of rust-lang/rust#37975. I did not investigate this further yet. |
Hm, I suppose force_alloc_system is newer. However, just setting that in Xargo does not work:
|
I reported this as rust-lang/rust#43637. I feel like something fishy is going on... |
The good news is that I locally managed to cross-compile libstd without having a C toolchain for the target! The bad news is that I have no idea how to make that work with the upstream rust-src component... here's what I did:
Unfortunately, it seems cross-compiling a dylib does need a C toolchain for the target, which is why I had to not build libstd as a dylib. It also doesn't seem to be possible to change the crate type depending on features (though maybe build scripts can do something here?), which means there currently is no way to upstream this. libstd being a dylib really is a huge pain. :/ The dylib build fails with
|
miri still doesn't run unpatched test cases after this:
This is fixed by adding the following to the test source:
This still fails, but that's because the allocator API emulation in I don't think there is a way to set the default allocator from outside the source... so even if we managed to get the right libstd, we'd still have to add this silly prelude to every single test. |
miri can insert that prelude to all compilations |
in the short term we can just add an additional travis matrix for 32 bit Appveyor already has bot 64 and 32 bit Macs are blocked on me not having a mac and no mac users being interested enough in miri to get it working with full mir |
Travis seems to only support 64bit :/ |
The allocator trouble is luckily gone now that the system allocator is the default. The However, that still leaves creating the dylib as a problem: Locally, this works for cross-building from 64bit Linux to 32bit Linux (likely because I have the right gcc toolchain installed), but cross-building to
|
https://github.com/rust-embedded/cross utilizes docker on travis and runs tests in QEMU.
|
Currently, Travis runs MIR-libstd tests only for the host architecture. Ideally, this should also be done for other architectures.
The text was updated successfully, but these errors were encountered: