[freetype2] Add MemorySanitizer

[bungeman]

The upstream freetype-testing project now pulls llvm-project and builds
libcxx and libcxx-abi and statically links against them to support the
use of C++ in the fuzzer driver.

[bungeman]

It looks like the one failure has something to do with Performing Test LIBCXXABI_HAS_NOSTDINCXX_FLAG - Failed which should have Succeeded and appears to have done so in the other builds. It isn't immediately clear why though. Will need to investigate.

[bungeman]

After much digging (getting the docker image to stick around by removing the --rm, being able to explore the docker image without it running the build by replacing compile with /bin/bash, convincing CMake to output the actual command to build and link for the LIBCXXABI_HAS_NOSTDINCXX_FLAG test, then testing various parts of the command) it looks like the issue is the -fsanitize-coverage addition this bot makes. The -fsanitize-coverage comes from compile_honggfuzzwhere it is added to the COVERAGE_FLAGS which are then added to CFLAGS and then CXXFLAGS.

In the LIBCXXABI_HAS_NOSTDINCXX_FLAG test the CXX fuzzer flags are present but must be disabled for the test (the test really just wants to know if a flag can be passed to the compiler and does not want to link against a sanitizer runtime), so the LLVM CMake configuration uses -fno-sanitize=all and -fno-sanitize-coverage= to disable any sanitizers (see libcxx/cmake/config-ix.cmake). Interestingly, use-fsanitize-coverage seems to require the ubsan runtime but does not provide it, which is the proximate cause of the link failure in this test. Note that -fno-sanitize-coverage= does not have an all option like -fno-sanitize does, so libcxx/cmake/config-ix.cmake needs to list out all of them. However, it appears to be missing -fno-sanitize-coverage=trace-pc-guard. Adding trace-pc-guard to libcxx/cmake/config-ix.cmake (and the one in libcxxabi) allows everything to work as expected.

This is all surprising because it appears that the llvm_libcxx has a honggfuzz_asan_llvm_libcxx fuzzer. However the llvm_libcxx project doesn't seem to be compiling at the moment for other reasons. The llvm_libcxxabi project seems to be green, but is doing something strange and does not itself appear to be building anything. The general llvm project also doesn't seem to be compiling for other reasons at the moment, so it isn't much help as an example either.

[DavidKorczynski]

After much digging (getting the docker image to stick around by removing the --rm, being able to explore the docker image without it running the build by replacing compile with /bin/bash, convincing CMake to output the actual command to build and link for the LIBCXXABI_HAS_NOSTDINCXX_FLAG test, then testing various parts of the command) it looks like the issue is the -fsanitize-coverage addition this bot makes. The -fsanitize-coverage comes from compile_honggfuzzwhere it is added to the COVERAGE_FLAGS which are then added to CFLAGS and then CXXFLAGS.

In the LIBCXXABI_HAS_NOSTDINCXX_FLAG test the CXX fuzzer flags are present but must be disabled for the test (the test really just wants to know if a flag can be passed to the compiler and does not want to link against a sanitizer runtime), so the LLVM CMake configuration uses -fno-sanitize=all and -fno-sanitize-coverage= to disable any sanitizers (see libcxx/cmake/config-ix.cmake). Interestingly, use-fsanitize-coverage seems to require the ubsan runtime but does not provide it, which is the proximate cause of the link failure in this test. Note that -fno-sanitize-coverage= does not have an all option like -fno-sanitize does, so libcxx/cmake/config-ix.cmake needs to list out all of them. However, it appears to be missing -fno-sanitize-coverage=trace-pc-guard. Adding trace-pc-guard to libcxx/cmake/config-ix.cmake (and the one in libcxxabi) allows everything to work as expected.

This is all surprising because it appears that the llvm_libcxx has a honggfuzz_asan_llvm_libcxx fuzzer. However the llvm_libcxx project doesn't seem to be compiling at the moment for other reasons. The llvm_libcxxabi project seems to be green, but is doing something strange and does not itself appear to be building anything. The general llvm project also doesn't seem to be compiling for other reasons at the moment, so it isn't much help as an example either.

Thanks for the thorough investigation here, I will take a look at the details regarding llvm_libcxx in the near future!