paulf

@david_chisnall @ZachWeinersmith "The bug I found a little while ago in some MISRA C code was of that form: their analyser had found it, someone had determined it was not a bug, and they were wrong." It's not just static analysis. Valgrind memcheck has a low false positive rate. For some reason many people seem to believe that if their program does not crash every time on their machine then it must be infallibly and absolutely correct. They might then report a "bug" or seek confirmation of the "false positive" that they have found.

@penguin42@mastodon.org.uk @stsquad@mastodon.org.uk There aren't that many. Valgrind VEX, DrMemory DynamoRio and Intel pin (if that it still maintained). As far as I understand there are fairly big differences between them. QEMU is just doing binary translation, which may be cross architecture. I guess that much of the complexity comes from the many architectures that it supports. DynamoRio (amd64,x86,arm.arm64) and pin (amd64 and x86 only) do dynamic binary instrumentatiion so roughly speaking the original opcodes pass through with added instrumentation. Valgrind VEX (amd64,x86,arm64,arm,ppc32,ppc64,mpis32,misp64,s390) does a more complete recompilation, converting to IR, performing register allocation and regenerating machine code. Valgrind has a fairly chronic lack of developers working on VEX. IBM s390 is well supported, and there is some work going on to share features like SSE4.1 between amd64 ans x86. There are big, long standing gaps in our amd64 coverage (avx512, fp16 and many more). Our floating point emulation is not great as well (rounding mode issues, no FPE support). QEMU is much bigger than the other projects. It is about twice the size of all of Valgrind (or about 4x the size of VEX). It also has many more contributors and commits - 5 to 10x what we get in Valgrind. As far as I know DynamoRio is pretty much a one man show. I don't know much about Intel pin. Lastly I believe that the architecture of these tools is fundamentally different (and thus difficult to combine) VEX is based on swtch/case code. QEMU is table driven DynamoRio and pin use dispatch tables and function calls.

@penguin42@mastodon.org.uk @stsquad@mastodon.org.uk syscall wrappers in Valgrind are a fairly big part of the code, but mostly they don't do much, just check the arguments and check pointers to memory that the syscalls read or write. And do some fd checking / monitoring. It's only process/CPU syscalls where Valgrind has to do a lot more intrusive work. For /proc and sysctls we do virtualise a few but for most of them we can just pass through to the originals. ELF (and macho) and DWARF readers are also sources of headaches for us.

@bytebro@mastodonapp.uk Originally Purify was developed by Pure Software. They merged with Atria. The merged company was bought by Rational who were bought by IBM. IBM sold PuifyPlus to UNICOM. As such it still exists https://www.unicomsi.com/products/purifyplus/ Free alternatives exist. Sanitizers work in a similar way to Purify (build time instrumentation). Sanitizers have separate functionality in Address Sanitizer (ASAN) and Memory Sanitizer (MSAN). You can't use them together and MSAN is only available with the LLVM toolchain. Valgrind is still going. I don't find it too difficult to use, but I do rather see it from the inside as it were.