Is it possible/desirable to include msan builds of libc++/libc++abi in test-release.sh? And if they’re built by test-release.sh, would they land where clang look for them with -fsanitize=memory -stdlib=libc++?
1 Like
What’s the use case for msan builds of libc++ ?
MSan, uniquely among sanitizers, is an all-or-nothing deal: MemorySanitizer · google/sanitizers Wiki · GitHub
So since you can’t build many C++ programs using MSan without having a sanitizer build of the C++ library, it really seems like a critical ingredient to a toolchain that supports MSan.
So is the idea that the script would produce 2 version of libc++, one with MSAN and one without?
Yes, sorry I should have been more clear about that. Multiple builds: the existing libc++/c++abi ones already built in test-release.sh and new ones built with msan.
And ideally the output msan library would get installed right where clang looks for it when -fsanitize=memory -stdlib=libc++ is present. And if there isn’t special handling for that case maybe we could add that to the driver.
If a libc++/libc++abi function transitively calls msan-instrumented malloc (which poisons the allocated memory), performs an uninstrumented store (which fails to unpoison the allocated memory), the result may trigger a subsequent false positive.
Therefore libc++/libc++abi need to be instrumented by msan.
glibc functions are intercepted, so they do not need to be instrumented.
Using msan really requires you to instrument everything except the libraries msan provides interceptors (read as: libc). I think providing msan builds will have very little benefit, because:
-
-fsanitize-memory -stdlib=libc++doesn’t magically use a different library path. msan users tend to specify-L. Different users may have different idea about the path. - llvm-project executables have a few system libraries which are neither intercepted nor instrumented: zlib, ncurses, libxml2, etc. They can also lead to false positives.
I suppose that’s true but there’s probably lots of people who use the clang+llvm releases who aren’t concerned with the design of the llvm-project executables or whether they have defects that msan could expose. Rebuilding their library dependencies with msan enabled is their challenge but we can help them on their way by providing a popular one of our dependencies (libc++/abi) built with msan.
-fsanitize-memory -stdlib=libc++doesn’t magically use a different library path. msan users tend to specify-L. Different users may have different idea about the path.
It would be ‘cool’ if clang’s driver did resolve the msan libc++ with those flags. But since it doesn’t do that now it would probably be a breaking change to start doing that. So instead we can just provide it at a predictable location to enable users to run msan testing without having to rebuild a C++ library.
@androm3da Another option would be to use the existing test-release.sh script to build an MSAN enabled version of the toolchain that only had the MSAN enabled libc++, then you wouldn’t have to worry about changing the linker driver.
That is a good solution, I hadn’t considered that. So for interested folks like me, we could upload two ubuntu x86_64 toolchains to a release, for example? One with ‘regular’ libc++ and one with msan libc++?
Yes, that’s what I was thinking.
Ok so to make it work we’d want a command-line argument to test-release.sh that would change the cmake args to build libc++/abi with msan? Or would passing a -DLLVM_USE_SANITIZER=Memory to the -configure-flags suffice? libc++/abi is built in all three stages and the -configure-flags apply to each?