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.
Thanks for reaching out, and thanks for planning on upstreaming your changes!
Regarding mingw and the sanitizers, @alvinhochun did a fair bit of work on that recently. I’d appreciate if you’d add him and myself on reviews you post. (I can’t promise I’ll be able to give a meaningful review each time, but I appreciate having an overview of what’s going on.)
I don’t think there’s anything in particular planned for mingw for the sanitizers currently. We (or primarily @alvinhochun) did a lot of cleanup to the point where the sanitizer tests do run successfully in mingw configurations for both i686 and x86_64. I do regular (nightly) runs of that on github actions - see e.g. Builds · mstorsjo/llvm-mingw@fec22cf · GitHub for a recent run. We’d at least want to avoid breaking this (or conversely - if something does get broken, we do notice it reasonably quickly).
The change of getting rid of the static asan configuration for Windows sounds good - it’s even less supported for mingw than what it is for the MSVC like configs.
I see that Microsoft enabled recovery mode as a dedicated flag continue_on_error. It would be nice to support at least halt_on_error as well for compatibility.