Bojun-Seo wrote: > I think the consensus in [this > thread](https://discourse.llvm.org/t/rfc-introduction-of-doublefreesanitizer-dsan/91363/16) > was having a dedicated tool that is a subset or very closely overlapping of > a range of other tools (ASan, Scudo, GWP-ASan, LSan, etc.) in compiler-rt > doesn't make much sense. You've evaluated against the no-instrument-ASan > option, but did you manage to prototype the **out-of-tree option**? Why does > it need to be part of compiler-rt? Because you do not need compiler > instrumentation, the flag `-fsanitize=doublefree` is a convenience and not > technically needed, and a pure runtime tool can be standalone out-of-tree.
Following @vitalybuka 's request, I am no longer planning to add this as a dedicated tool in compiler-rt. Instead, I am implementing double-free detection as an extension to LSan. Your points are very reasonable. While there are trade-offs, I also agree that keeping this functionality out-of-tree is a viable and good option. I would like to gather more community feedback on the RFC. Between the two approaches — extending LSan or maintaining it out-of-tree — which one do people prefer? I will follow the consensus. https://github.com/llvm/llvm-project/pull/213846 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
