I think at very least we should keep correct Win ABI and performance as a priority. E. g., if we can express the unwind through syscall dispatcher with CFI we can do that, but IMO building this whole thing around Valgrind is wrong. Maybe there are other ways to do it, keeping Valgrind solely on the Unix part (I don’t know if that is possible). Or maybe we can develop some parts for the tool which will explicitly support Wine specifics.
On 16 Oct 2022, at 19:48, Zebediah Figura zfigura@codeweavers.com wrote:
On 10/16/22 19:28, Paul Gofman wrote:
In fact, I think it is a specific part of more general question: are we ready to officially support Valgrind? That would mean that we need to make sure any future changes in these areas do not break it, accept valgrind related bugs and regressions? My feeling is it will create more burden than it removes.
Personally, I'd cast my vote for supporting it. Valgrind has been an invaluable tool in the past, and I think it's worth bending over backwards regarding things like the PE/Unix split to make sure it keeps working.
Of course, I also think that we should make a good effort to fix bugs in the right place, and at least some of these are probably valgrind bugs, but the ultimate point is the same.