QEMU issues

[japaric]

Update

Trying to run the test suite on QEMU for some targets crashes QEMU

• armv7-unknown-linux-gnueabihf
• mips-unknown-linux-gnu
• powerpc64-unknown-linux-gnu
• powerpc64le-unknown-linux-gnu

I'm not quite sure what's the exact problem for each target but some possible causes:

• The std binaries for the target are "broken". Most likely, some C binding in libc is wrong.
• We are using the wrong QEMU variant (qemu-ppc64le).
• "Just" a problem with multithreading. This leads to sporadic failures.

In some cases, using QEMU's system emulation instead of user emulation might fix the problem.

---

Example.

Emphasis on sometimes. This is weird because (a) as of e5ab308, the test suite is deterministic and (b) I'm using RUST_TEST_THREADS=1 to "prevent" multithreading (QEMU is known to have problems handling multiple threads) but I guess this last part is impossible because detecting a panic requires at least two threads.

[Amanieu]

Yes, that looks like qemu-user is failing due to threads. There's not much you can do about it. One way to solve it would be to use qemu-system-arm instead and run the tests in a full VM (though you can probably get away with just the kernel and running the test with init=/test, in which case all you need is a kernel image).

[japaric]

@Amanieu Thanks for taking a peek.

Yes, that looks like qemu-user is failing due to threads.

What I feared. 🙀

One way to solve it would be to use qemu-system-arm instead and run the tests in a full VM

Sounds annoying. Know of any place where I can get an ARM kernel image? For the rootfs I think I can use one of ubuntu-core's.

though you can probably get away with just the kernel and running the test with init=/test, in which case all you need is a kernel image

Hmm, I'm not sure. The test binary is dynamically linked and depends on libc and other C libraries.

[Amanieu]

This might be helpful.

[japaric]

mips-unknown-linux-gnu
powerpc64-unknown-linux-gnu
powerpc64le-unknown-linux-gnu

QEMU for these three targets appears to be flat out broken. Even this simple program causes a segfault when executed with QEMU for these targets:

int main() { return 0; }

This issue have been reported upstream but there has been no action. Also, someone claims that the 32-bit version of qemu-$TARGET doesn't segfault on amd64. Might try that.

[japaric]

Also, someone claims that the 32-bit version of qemu-$TARGET doesn't segfault on amd64. Might try that.

And, weirdly enough, it actually works! At least on MIPS. Will send a PR.

[japaric]

And, weirdly enough, it actually works! At least on MIPS. Will send a PR.

Fixed the mips and ppc64 targets. The trick didn't work on the ppc64le target.

[japaric]

Switching Travis to exclusively use Docker (Ubuntu 16.04) fixed the flakiness of the ARM targets. The ppc64le target still doesn't work (QEMU appears to be busted) but I'm OK with that; we got 16 of 17 targets working so I'm gonna close this.