<div dir="ltr">Hi,<div><br></div><div>TL;DR I plan to pull interceptors for operator new/delete in TSan and MSan into separate static libraries: tsan_cxx and msan_cxx.</div><div><br></div><div>Currently, static UBSan and ASan runtimes have parts that are linked into the executable in C++ mode only (ubsan_standalone_cxx, and asan_cxx):</div><div>1) it's necessary for UBSan, as handlers in ubsan_standalone_cxx use functions from C++ ABI (dynamic_cast), which will be unavailable in plain C executable.</div><div>2) we did this in ASan as a step in <a href="https://code.google.com/p/address-sanitizer/issues/detail?id=295">https://code.google.com/p/address-sanitizer/issues/detail?id=295</a> (making operator new/delete more standard-compliant). We decided that at some point we may, for instance, build asan_cxx with different flags to throw bad_alloc from operator new.</div><div><br></div><div>UBSan runtime was recently embedded into ASan (in particular, ubsan_cxx is now a part of asan_cxx). It solved a number of problems, but made TSan+UBsan and MSan+UBSan combinations temporarily unavailable. I want to fix that.</div><div><br></div><div>It means that UBSan will be embedded into both TSan and MSan runtimes in the same way as in ASan, and ubsan_cxx should be a part of *some* tsan_cxx and msan_cxx. I think that it's a reasonable step to factor new/delete operators out to tsan_cxx and msan_cxx to make all sanitizers consistent, and potential future changes to these operators easier.</div><div><br></div><div>I plan to start implementing these changes early next week. Please let me know if you have objections.</div><div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Alexey Samsonov<br><a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a></div></div>
</div></div>