<div dir="ltr">Hi Dean. <div><br></div><div>The sanitizers don't use any of the C++ std library. </div><div>More than that, they don't include *any* system headers in most of the sources (exception is some OS-dependent .cc files). </div><div><br></div><div>This rule is *somewhat* documented, e.g. </div><div>tsan/rtl/tsan_rtl.h:<br><br>//   - No system headers included in header files (*).<br>//   - Platform specific headres included only into platform-specific files (*).<br><br>It's enforced only by code review, although if one attempts to use stl in e.g. asan some tests will most likely break. </div><div>If you can suggest a simple way to enforce this at build time -- let's do it. </div><div><br></div><div>libFuzzer on the contrary uses STL, including the containers, and it causes all sorts of problems. </div><div>(I've anticipated it from the beginning, but just couldn't force myself to not use STL).</div><div><br></div><div>My recommendation is to ban all of C++ std lib in xray unless you find a way to "privatize" the bits of STL you are using. </div><div>Ideally, those bits will be header-only and you'll be able to change the namespace for STL. </div><div>See e.g. a long discussion in <a href="https://reviews.llvm.org/D37631" rel="noreferrer" target="_blank" style="font-size:12.8px">https://reviews.llvm.org/<wbr>D37631</a> (trying to privatize STL in libFuzzer)</div><div><br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 11, 2017 at 4:07 AM, Dean Michael Berris <span dir="ltr"><<a href="mailto:dean.berris@gmail.com" target="_blank">dean.berris@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Kostya, Evgenii, and David,<br>
<br>
Recently I've been making some incremental changes to the XRay runtime implementation in compiler-rt to reduce the reliance on the C++ standard library components that might have external linkage dependencies. This involves not using containers from the STL and not using non-trivially destructible C++11 thread_local objects.<br>
<br>
I was wondering whether the sanitisers follow an explicit policy of not depending on the C++ standard library or avoiding linkage/ABI issues that come up when building the sanitisers with C++ standard library dependencies. If it does, do we document these policies somewhere? If we don't document it somewhere, does it make sense for us to do so and maybe potentially enforce it at build time?<br>
<br>
One of the policies I can think of is not to use *anything* from the C++ standard library even if they are templates anyway (e.g. std::unique_ptr<...>, std::shared_ptr<...>, std::tuple<...>, std::aligned_storage<...>, etc.). The downside to this would be myriad, where we'd need to implement analogues of these ourselves or resort to only things we can use from libc. I'm not sure how this could be automatically enforced, maybe potentially through a blacklist on `std::` types.<br>
<br>
A slightly more permissive policy might be to allow using some of these types but not in any of the exposed interfaces and not require any runtime dependencies from the C++ standard library. This might be possible to enforce by checking the external/dymamic symbols in the runtime archives. I'm not sure though whether it's even safe to assume that the templates wouldn't introduce some weird ABI constraint even if the types don't cross the API boundaries.<br>
<br>
I'm curious what the sanitisers currently do and what techniques/conventions we can follow on the XRay implementation that would be helpful to emulate as well.<br>
<br>
In a similar vein, how do the sanitisers handle making ABI breaking changes? For the published types, is there a symbol naming policy and explicit deprecation/support horizon? How about API stability, do we intend to keep the API stable across N stable releases?<br></blockquote><div><br></div><div>We generally don't promise compatibility between the compiler and rt from different revisions. </div><div>However, just in case, we do a version mismatch check (e.g. see lib/asan/asan_init_version.h)</div><div><br></div><div>--kcc </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Your thoughts and feedback would be most appreciated.<br>
<br>
Cheers<br>
<span class="gmail-HOEnZb"><font color="#888888"><br>
-- Dean<br>
<br>
</font></span></blockquote></div><br></div></div>