I work on the MSVC libraries team over at Microsoft and we currently ship a fork of LLVM14’s asan that’s been modified to work better with msvc and the msvc toolchain (link.exe, the crt, etc). I’m starting to upstream changes from this fork, and in the long term we’d like to upstream essentially everything and work in the open on LLVM main.
I know that there are other folks out there working on asan-on-windows, particularly to support mingw, and we’d like to avoid stepping on their toes, if not collaborate by avoiding doing duplicate work.
Some of our more major additions are:
“One DLL”. Removal of the static asan runtime and modifications of the dynamic runtime to work with all versions of the CRT. This makes it so that building asan as debug vs release just means asan is debug or release, and all “flavors” of the asan dll can be linked against all executables. The static version of asan was removed because getting it to work reliably required a ton of hacks due to how the windows dynamic loader model works.
“Continue on error”. Some of our users wanted to use asan with their project but found that they had so many memory errors that having asan crash the process immediately made it much harder to fix everything than if it logged the error and continued on the best it could. I think there is a similar feature on linux, but I’m not familiar with exactly how it works.
I’ll be preparing a few more of our allocator interception changes (which are applicable for all platforms, not just windows) and then probably the “One DLL” changes. These would completely remove the asan static runtime on windows, so I’m curious if anyone is working on it or using it (from looking at the tests it seems pretty broken right now, in any event).
I would love to hear what people are working on mingw-wise, and if there’s anything our branch does, or might do, that others working on asan-on-windows would find particularly useful.