On Wed May 14 23:48:03 2025 +0000, Jinoh Kang wrote:
maybe implement some different targeted Wine-specific improvements to
heap debugging isntead? We would lose nothing that way if ASAN was just some extra checks to heap alloc/dealloc. In fact ASAN is not limited to heap memory; the main value of ASAN lies in the extensive instrumentation on every indirect load/store (whether heap, stack, or static), sort of like Valgrind but more lightweight without the VEX IR. For example it can detect erroneous reading beyond buffer boundary, something a heap verifier won't be capable of.
IMO it doesn't fit very well into Wine purpose. E. g., things like existing or planned gdb integration changes are much smaller, don't expose Wine internals and at the same time help debugging apps under Wine, not just Wine itself. If some limited changes not affecting things at runtime anyhow (including not exposing any Wine-specific stuff) could work that would be great (like there were something about ASAN in ntdll/heap.c, not sure maybe that is supposed to work in some limited sense??), but IMO making so lot of system places revolve around ASAN requirements doesn't worth it. Also, there is so lot of special cases with what Wine is doing, somehow I suspect there would be more than currently considered in the MR.