
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hello,<div class=""><br class=""></div><div class="">I am currently porting memory sanitizer to a custom platform, and discovered some strange things in the existing implementation.</div><div class=""><br class=""></div><div class="">1. clang/llvm currently hardcode the list of supported platforms and disallow the use of a standalone msan implementation.</div><div class="">I suppose the solution here is to submit a patch similar to <a href="https://reviews.llvm.org/D18865" class="">https://reviews.llvm.org/D18865</a>, which will provide the necessary arguments to configure the layout.</div><div class="">I have it ready here. Will this approach be fine for the llvm dev team, and may I post it for the review then?</div><div class=""><br class=""></div><div class="">2. There exists a concept of -fsanitize-blacklist argument, which is supposed to exclude source locations from being instrumented by the sanitizers.</div><div class="">Normally this works without issues, but I discovered that you cannot compile compiler-rt msan implementation with -fsanitize=memory even if the whole location is blacklisted (that much I can confirm from the invocations of CodeGenModule::isInSanitizerBlacklist function).</div><div class="">What happens is that for some reason memory sanitizer:</div><div class="">— still tries to partially instrument the blacklisted code;</div><div class="">— does not check whether its global memory storage variables are already defined.</div><div class="">The second issue, present in MemorySanitizer::initializeCallbacks, adds a second copy of storage global variables when compiling <a href="http://msan.cc" class="">msan.cc</a> (e.g. __emutls_v.__msan_retval_tls.63, __emutls_v.__msan_param_tls.65), and this results in an undefined reference during the linkage.</div><div class=""><br class=""></div><div class="">Here the question is what was initially intended to be done. I know that compiling blacklisted asan runtime code with -fsanitize=address is just fine, and this is what Apple actually does in XNU KASAN implementation.</div><div class="">I kind of expected it to be the right way to do for msan as well, is this just a bug? If it is not, should I compile msan runtime without -fsanitize=memory in this case, and in fact asan runtime too?</div><div class=""><br class=""></div><div class="">3. Other than that, I see that memory sanitizer is currently implemented only for 64-bit platforms. While I am aware of the issues behind requiring a lot of memory to use msan, are there any other issues for not supporting 32-bit?</div><div class=""><br class=""></div><div class="">Best regards,</div><div class="">Vit</div></body></html>