QEMU's user mode emulation is a bit unloved, though. We did manage to fix some longstanding bugs a while back, but it's still I think a bit unreliable on complex multithreaded apps. It could really use somebody with a few months to work on testing some big apps (eg node.js), dig into why they're not working and fix the issues. But many more people and companies care about QEMU for KVM support and for full system emulation, so those get the lion's share of maintenance effort...

I don't quite have the domain knowledge required to tie weird/confusing app breakages back to specific QEMU issues, but I'm curious what "testing" actually means. For example, using american fuzzy lop to run apps inside qemu-user-??? could be one way to generate a steady stream of noise/data.

Using AFL like this sounds like it could be fun to experiment/play with, although I don't know if it has the necessary comprehension to handle "emulation or host program running guest program" semantics at the moment, where two programs (the emulator and the guest program) both need to be tracked for best results.

These ideas don't exactly find any time to fix bugs, however...

No, I mean "try big complicated programs, see whether they fail or not, narrow down what's going wrong". What we need to do is get the expected cases to work. AFL is good for checking that weird corner cases don't blow up, but we don't care so much about those for user-mode, because by definition we allow the guest app to call any syscalls it likes -- you don't need to overrun a buffer to run arbitrary code because you're already running arbitrary code. (Also, there are a number of things that are technically permitted and supported by a native Linux kernel but which QEMU's user-mode emulation doesn't support, but which don't matter because real-world programs don't use those corner cases. AFL can't tell the difference between "bug that doesn't matter" and "bug that real code will hit".)

Ohhhh, I see. Woops.

Thanks for explaining that. I was actually aiming to describe code coverage in my previous comment, but completely overshot that and went to fuzzing instead, lol.

I just found https://coverage.nodejs.org/, which you're probably already aware of. Apparently it uses istanbul for JS coverage and gcov for V8.

Also, https://github.com/nodejs/node/blob/master/CONTRIBUTING.md#s... says that `make test` runs tests, presumably from https://github.com/nodejs/node/tree/master/test. Thinking about it, if Node.js' tests pass running under QEMU usermode, that should be good evidence that QEMU usermode is working too, right?

Looking further afield, I wonder if running tests from other large projects - Qt comes to mind, although you could also be utterly insane and try GCC/LLVM xD - could be used to exercise QEMU.

As an aside, I'm very curious to learn what QEMU's corner cases are, if just so that if I want to do horrible things in ELF files one day I know what won't work. :P