AddressSanitizer with MSVC linker errors

Hi,

I just downloaded Windows / MSVC Clang installer. Integration with VC++2012 went fine and I am able to build executables with LLVM toolchain (YEY!) but after adding “-fsanitize=address” I am getting:

1>main.obj : error LNK2019: unresolved external symbol ___asan_report_store4 referenced in function _main
1>main.obj : error LNK2019: unresolved external symbol ___asan_report_load4 referenced in function _main
1>main.obj : error LNK2019: unresolved external symbol ___asan_report_load1 referenced in function _main
1>main.obj : error LNK2019: unresolved external symbol ___asan_init_v3 referenced in function _asan.module_ctor

I did see Chandler using it in his talk on GN2013 so I assume I am doing something wrong.

Since this is my first post on this list I also want to thank all you guys for this awesome compiler. I recently have of pleasure using it on OS X (tho XCode sucks) and it would be just the best thing if I could also switch to Cland on Windows. Thanks again!

Regards,
Szymon Gatner

TL;DR, add clang_rt.asan-i386.lib to the list of libraries you link and use the static, release CRT (/MT).

Thanks for trying it!

The problem is that you have to link the AddressSanitizer runtime library to resolve those symbols. It’s distributed as a static library called clang_rt.asan-i386.lib and added to the linker search path by the VS integration.

However, MSBuild invokes the link.exe tool directly, so there isn’t an opportunity for clang to inject the ASan RTL onto the link line like we do on Unix. We would inject it into .drectve at compile time, but you actually need to use a different asan RTL depending on whether you are building a DLL or an exe. At compile time, we’re just making .obj files, and there’s no flag that can tell us if we’re building objs for a DLL.

Speaking of which, if you are making a DLL, use clang_rt.asan_dll_thunk-i386.lib. =/

You also have to use the static, release CRT to avoid symbol conflicts between the asan RT and the CRT, because in essence they are both trying to provide malloc, and coexisting can be tricky.

I recommend wrapping up these options in a separate “ASan” configuration parallel to Debug/Release, which we showed in the demo.

Timur knows more, he’s been working on asan in particular.

You could pass extra command line options via “LINK” environment variable. That might help?

That works, thanks!