Fix references to required libraries when building LLVM with ASAN and MultiThreaded[Debug] on Windows

[dgg5503]

After #81677, statically linking ASAN under Windows is no longer supported. Therefore, when using Clang built past 53a81d4 to build LLVM / Clang with -DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreaded[Debug] -DLLVM_USE_SANITIZER=Address, a different set of dependent libraries must be linked. This is mentioned in the description of #81677 and also in https://devblogs.microsoft.com/cppblog/msvc-address-sanitizer-one-dll-for-all-runtime-configurations/.

[vitalybuka]

LGTM, but please wait for @barcharcraz

[dgg5503]

Ping @barcharcraz

[dgg5503]

Ping @barcharcraz

[dgg5503]

Ping @barcharcraz

[dgg5503]

Ping @barcharcraz

[dgg5503]

Ping @barcharcraz -- @vitalybuka , would it be OK to merge this in if I do not get a response this week from @barcharcraz ?

[barcharcraz]

I have seen your pings and will look today :)

[barcharcraz]

lgtm

but I question if we really need to be messing with the linker flags here in the first place. This is exactly what the clang driver does if you link through it with /fsanitize=address or what link.exe does when it sees the asan directive.

[dgg5503]

lgtm

but I question if we really need to be messing with the linker flags here in the first place. This is exactly what the clang driver does if you link through it with /fsanitize=address or what link.exe does when it sees the asan directive.

Thanks for the review @barcharcraz !

I will verify this some time next week.

[dgg5503]

Hi @barcharcraz ,

I re-reviewed these changes and can confirm they are still necessary in the case of building LLVM / Clang with -DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreaded[Debug] -DLLVM_USE_SANITIZER=Address -- at least when building using Clang-CL and lld-link from the latest Clang / LLVM binary package (20.1.7).

but I question if we really need to be messing with the linker flags here in the first place. This is exactly what the clang driver does if you link through it with /fsanitize=address or what link.exe does when it sees the asan directive.

It indeed does look like the appropriate libraries will be added automatically as per:

llvm-project/clang/lib/Driver/ToolChains/MSVC.cpp

Lines 203 to 228 in fccab5d

	if (TC.getSanitizerArgs(Args).needsAsanRt()) {
	CmdArgs.push_back(Args.MakeArgString("-debug"));
	CmdArgs.push_back(Args.MakeArgString("-incremental:no"));
	CmdArgs.push_back(TC.getCompilerRTArgString(Args, "asan_dynamic"));
	auto defines = Args.getAllArgValues(options::OPT_D);
	if (Args.hasArg(options::OPT__SLASH_MD, options::OPT__SLASH_MDd) ||
	llvm::is_contained(defines, "_DLL")) {
	// Make sure the dynamic runtime thunk is not optimized out at link time
	// to ensure proper SEH handling.
	CmdArgs.push_back(Args.MakeArgString(
	TC.getArch() == llvm::Triple::x86
	? "-include:___asan_seh_interceptor"
	: "-include:__asan_seh_interceptor"));
	// Make sure the linker consider all object files from the dynamic runtime
	// thunk.
	CmdArgs.push_back(Args.MakeArgString(
	std::string("-wholearchive:") +
	TC.getCompilerRT(Args, "asan_dynamic_runtime_thunk")));
	} else {
	// Make sure the linker consider all object files from the static runtime
	// thunk.
	CmdArgs.push_back(Args.MakeArgString(
	std::string("-wholearchive:") +
	TC.getCompilerRT(Args, "asan_static_runtime_thunk")));
	}
	}

However, at least from the CMake options I'm using and my build environment, it appears that linking is invoked directly via the linker rather than linking via the compiler driver invoking the linker. Therefore, unless there's a CMake flag or some other bits of configuration I may be overlooking (please let me know if that is the case), it seems like this change is required.

I will wait a few more days before merging to give you time to reply in-case there's extra discussion that may be worth having.

Thanks again for reviewing, sorry if my pings were a bit annoying 😅...