mstorsjo wrote: > > 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.
Ah, right, these are all very good explanations for why this is harder than the preexisting cases of multiple statically linked CRTs within the same process. Thanks! > > 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. Yeah, I totally agree, there's no practical need for allowing asan to be linked in another way. Especially as it works for both MSVC and mingw environments. > It occurs to me that this probably requires changes to the gyp build files. No, the extra build systems doesn't need to be updated in general, that's up to whoever maintains them to sync them afterwards. Regular contributors only need to make sure the cmake build works. (And unless one is able to test that the changes to the third party build systems actually is entirely right, it's usually better to leave them untouched, so it can be done cleanly in one commit, rather than do a half-broken update to the files.) 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
