[PATCH] D51018: [sancov] Accommodate sancov and coverage report server for use under Windows

Douglas Gliner via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Mar 4 12:57:10 PST 2020


dgg5503 added a comment.

So I've finally taken the time to figure out why these tests fail on s390x using QEMU. When `.sancov` files are loaded into memory and the header is checked in `isCoverageFile`, the check fails presumably due to endianess. For example, the sancov header magic for  `test-linux_x86_64.0.sancov` is expected to be `0xC0BFFFFF` but is read as `‭0xFFFFBFC0‬` on big endian systems. I assume the same issue is causing the tests to fail when ran on ppc64be. I am not at all familiar with how other parts of LLVM handle endian differences when reading files from memory using `MemoryBuffer::getFile` or equivalent. I'd guess there'd be a portable method since `llvm-objdump -d /test/tools/sancov/Inputs/test-linux_x86_64` returns the identical output when ran on both s390x and x86_64, but perhaps there are other factors in play that I'm overlooking. What are the expectations regarding cross platform compatibility with sancov? Is it reasonable to expect sancov to be able to parse and provide coverage information for any `.sancov` and binary compiled for a target supported by LLVM on any platform? Or should users be expected to use `.sancov` files on the same host that generated them?

For reference, all of these tests passed on Windows when parsing the Linux sancov test file. So I guess what I'm really asking is, should we expect "cross-endian" support? If not, I wouldn't mind adding some `.sancov` binary files created on a big endian system just so these tests pass accordingly.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D51018/new/

https://reviews.llvm.org/D51018





More information about the llvm-commits mailing list