On Wed May 14 23:53:11 2025 +0000, Paul Gofman wrote:
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.
the additions to ntdll are mostly self-contained in the two `asan_rtl.c` files, if necessary they can be moved out into a separate folder in `dlls/`. and really has no impact on wine whatsoever if asan is not enabled.
the most invasive changes to ntdll are in `heap.c`, but that's not mandatory. i can write an asan specific heap allocator and make the whole thing self-contained.
the rest of the changes are:
- handling `__WINE_FRAME` exceptions. (can we get rid of these and use SEH?) - mapping shadow memory in `virtual_init`. - putting stuff in unused slots in TEB. this we already do for `ntdll_thread_data`, and games with anti-cheat don't run on asan-enabled wine isn't that big of a compromise.
which IMHO is worth it for what asan will give us (look at the long list of bugs already found).