[clang] [compiler-rt] [asan][windows] Eliminate the static asan runtime on windows (PR #81677)

Charlie Barto via cfe-commits cfe-commits at lists.llvm.org
Fri Feb 16 13:24:15 PST 2024


barcharcraz wrote:

> > The core reasoning is that asan is a "only one allowed per process" type thing (you can't have one copy of the asan runtime handling a malloc while a different one handles the corresponding free).
> 
> Not to distract from the direction taken here (which I do agree seems reasonable, even if I haven't had time to look closer at the PR yet) - but, when using the static CRT in general, doesn't the same concern apply there as well? I.e. when using the static CRT, care must be taken that the same CRT instances does frees as did the allocation. But I guess there are other asan-related aspects that makes it even more of a mess.

Yes, it does, but my understanding is that this requirement is slightly weaker than what asan needs. As long as you _do_ match mallocs and frees things work fine, because the data that's shared is shared through kernel32.dll, ntdll.dll, or the kernel and page table. If asan allowed this it would need some way of mapping memory to the correct global structures, and some way of figuring out who gets to handle the shadow memory area and where to get the stack information for a given allocation upon an invalid access. We can't rely on "matching" allocations with invalid accesses because it's far from uncommon for a memory error to relate to memory allocated in another DLL. Maybe the static-linked asans could have some voting mechanism to settle on a "lead" copy of asan or something. It's not impossible but making things work well is a ton of work for something the loader can do anyway. Before this change we still relied on only one copy of asan being around, but the functions would be exported from the main exe with the "dll thunk" using GetProcAddress to call them. 

> Also secondly, when discussing these details - how the asan runtime is built in one, specific way, while it is used for applications that can use a different CRT configuration ....

It might be possible to support copies of the asan runtime built with the static CRT, it's just not that useful and we'd rather keep one configuration and spend time making it work perfectly for all instrumented programs.


https://github.com/llvm/llvm-project/pull/81677


More information about the cfe-commits mailing list