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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
