Address Sanitizer-like functionality on MSVC

前端 未结 2 1868
梦如初夏
梦如初夏 2021-01-31 05:26

Coming from Linux/gcc/clang I find myself working more and more on Windows/Visual Studio.

What I am really missing there is the address sanitizer (bounds checking, leaks

2条回答
  •  悲哀的现实
    2021-01-31 06:12

    At least ASan and Ubsan from clang are supposed to work on Windows, with some limitations. These can be used with msvc toolchains using clang-cl as a drop-in replacement for cl.exe - google seems to be working on this, mozilla too.

    Issues that I am aware of (and that keeped me from using it myself until now):

    • linking with the required libraries is not automatic. There are two versions of them, depending on how the CRT is linked in your application ( /MT means static CRT, /MD means dynamic CRT, the latter is typically used in Qt). To find the required linker parameters, open Visual Studio command prompt, add clang bin folder to the path, and compile a simple main.cpp (empty main function) with verbose options with clang-cl like this: clang-cl -v /MD -fsanitize=address main.cpp The required link.exe command is in the end of verbose output, extract the required libs for linking from there.

    • only release builds are supported on Windows

    • no support for exceptions on Windows ( see this issue)

    • there doesn't seem to be much further work on the Windows port, the wiki e.g. is terribly outdated (last change in 2015), so I doubt that many people are using this productively. So getting help from other users online might be quite hard ...

    Talking about other alternatives on Windows, there are:

    • Appverifier (coming with Windows SDK)
    • Dr Memory(currently unmaintained on Windows according to some comments on its issue tracker, meaning that it's e.g. completely unusable for Qt and everybody who uses SSE 4.2 instructions, see here and here )
    • Intel Inspector (commercial).

    Sanitizers and Valgrind on Linux IMO are much more advanced and/or have much better performance than these tools, so keeping an application building on Linux seems the best idea, at least when working with a cross-platform toolkit like Qt (as you are mentioning).

提交回复
热议问题