<div dir="ltr">Sanitizers such as MSAN require the entire program to be instrumented, anything less leads to plenty of false positives. Unfortunately this can be difficult to achieve, especially for the C and C++ standard libraries. To work around this the sanitizers provide interceptors for common C functions, but the same solution doesn't work as well for the C++ STL. Instead users are forced to manually build and link a custom sanitized libc++. This is a huge PITA and I would like to improve the situation, not just for MSAN but all sanitizers. I'm working on a proposal to change this. The basis of my proposal is:<div><div><br></div><div>Clang should install/provide multiple sanitized versions of Libc++ and a mechanism to easily link them, as if they were a Compiler-RT runtime.</div><div><br></div><div>The goal of this proposal is:</div><div><br></div><div>(1) Greatly reduce the number of false positives caused by using an un-sanitized STL.</div><div>(2) Allow sanitizers to catch user bugs that occur within the STL library, not just its headers.</div><div><br></div><div>The basic steps I would like to take to achieve this are:</div><div><br></div><div>(1) Teach the compiler-rt CMake how to build and install each sanitized libc++ version along side its other runtimes.</div><div>(2) Add options to the Clang driver to support linking/using these libraries.</div><div><br></div><div>I think this proposal is likely to be contentious, so I would like to focus on the details it. Once I have some feedback on these details I'll put together a formal proposal, including a plan for implementing it.</div><div>The details I would like input on are:</div><div><br></div><div>(A) What kind and how many sanitized versions of libc++ should we provide?</div><div>---------------------------------------------------------------------------------------------------------------</div><div><br></div><div>I think the minimum set would be Address (which includes Leak), Memory (With origin tracking?), Thread, and Undefined.</div><div>Once we get into combinations of sanitizers things get more complicated. What other sanitizer combinations should we provide?</div><div><br></div><div>(B) How should we handle UBSAN?</div><div>---------------------------------------------------</div><div><br></div><div>UBSAN is really just a collection of sanitizers and providing sanitized versions of libc++ for every possible configuration is out of the question.</div><div>Instead we should figure out what subset of UBSAN checks we want to enable in sanitized libc++ versions. I suspect we want to disable the following checks.</div><div><br></div><div>* -fsanitize=vptr</div><div>* -fsanitize=function</div><div>* -fsanitize=float-divide-by-zero</div><div><br></div><div>Additionally UBSAN can be combined with every other sanitizer group (ie Address, Memory, Thread).</div><div>Do we want to provide a combination of UBSAN on/off for every group, or can we simply provide an over-sanitized version with UBSAN on?</div><div><br></div><div>(C) How should the Clang driver expose the sanitized libraries to the users?</div><div>-------------------------------------------------------------------------------------------------------------</div><div><br></div><div>I would like to propose the driver option '-fsanitize-stdlib' and '-fsanitize-stdlib=<sanitizer>'.</div><div>The first version deduces the best sanitized version to use, the second allows it to be explicitly specified.</div><div><br></div><div>A couple of other options are:</div><div><br></div><div>* -fsanitize=foo: ¬†Implicitly turn on a sanitized STL. Clang deduces which version.</div><div>* -stdlib=libc++-<sanitizer>: Explicitly turn on and choose a sanitized STL.</div><div><br></div><div>(D) Should sanitized libc++ versions override libc++.so?</div><div>-------------------------------------------------------------------------------------------</div><div><br></div><div>For example, what happens when a program links to both a sanitized and non-sanitized libc++ version?</div><div>Does the sanitized version replace the non-sanitized version, or should both versions be loaded into the program?</div><div><br></div><div>Essentially I'm asking if the sanitized versions of libc++ should have the "soname" libc++ so they can</div><div>replace non-sanitized version, or if they should have a different "soname" so the linker treats them as a separate library.</div><div><br></div><div>I haven't looked into the consequences of either approach in depth, but any input is appreciated.</div><div><br></div><div>Conclusion</div><div>-----------------</div><div><br></div><div>I hope my proposal and questions have made sense. Any and all input is appreciated.</div><div>Please let me know if anything needs clarification.</div><div><br></div><div>/Eric</div><div><br></div><div><br></div><div><br></div><div><br></div></div></div>