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