rnk wrote: I'm short on time, so I can't respond to all the discussion here, but at a high level, I agree with this direction and it's something I discussed with Microsoft folks working on ASan in the past, so I'm happy to see it come together.
There is a great deal of build configuration complexity involved in supporting the static/dynamic variants. As mentioned, there should only ever be one copy of the ASan runtime active in a process address space. Making the static ASan build work properly required linking against different libraries depending on whether an EXE or a DLL was being produced, and this knowledge had to be encoded in every build system using ASan on Windows, since the linker is invoked directly, rather than running through the Clang driver. Ultimately, there is no real gain to be had from statically linking ASan. You ultimately have to make something equivalent to a shim import library for any DLL containing ASan instrumented code, so you might as well use the dynamic model and standardize. I think the biggest risk here is, as usual, portability of weak symbol registration schemes. `__sanitizer_default_options` is registration-free, and there are some substantial advantages to making initialization order fiasco problems into duplicate symbol linker errors. In the end, the simplification benefits probably outweigh the portability issues. I'll look at this some more and provide more feedback and hopefully other next steps. 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
