Valgrind support requires a fork, which I've published to https://gitlab.winehq.org/rbernon/valgrind. The fork implements loading DWARF debug info from PE files, instead of the old and broken upstream PDB support. I've tried to upstream these changes a long time ago but didn't receive any feedback.
I think we could maybe consider keeping a fork, which I'm happy to maintain, as the changes aren't too large. We may want to investigate adding 32-on-64 support, which may require a bit more changes (to VEX specifically, because its amd64 guest doesn't support segment register manipulation).
The changes here are not all related to Valgrind, and I'll create separate MR for those which may make sense independently from Valgrind / GDB.
Also included is a suppression file to silent some annoying false positives, many of which are coming from the cross-stack accesses during syscalls, which are confusing Valgrind's stack heuristics. One can try this out with something like:
`WINELOADERNOEXEC=1 valgrind --suppressions=tools/valgrind.supp wine64/loader/wine64 wine64/programs/winecfg/winecfg.exe`
--
v12: ntdll: Avoid writing to invalid memory in i386 unix dispatcher.
ntdll: Fix incorrect i386 call_user_mode_callback CFI.
ntdll: Avoid marking freed block header as undefined for valgrind.
ntdll: Force HEAP_TAIL_CHECKING_ENABLED flag with valgrind.
ntdll: Fix valgrind notifications from ntdll.so.
ntdll: Import valgrind headers for PE side ntdll.
loader: Implement SystemTap RTLD probes.
configure.ac: Check for systemtap sys/sdt.h header.
gitlab: Install systemtap-sdt-dev packages.
ntdll: Maintain a PE module link map and expose it to GDB.
loader: Expose a shadow copy of ld.so link map to GDB.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1074
On Fri Nov 10 20:03:47 2023 +0000, Vixea wrote:
> It's probably because it's being software rendered so it takes a second
> to actually update the content of the window
> Side note: you can still see it on xWayland it's just less noticeable
> like I said it's noticable on wayland because of software rendering
Hi! This is a known issue, see https://gitlab.winehq.org/wine/wine/-/merge_requests/3686#note_43830 for a description of why this is happening more (but not exclusively) with the Wayland driver. The aforementioned comment describes the effect with motion events, but it's the same cause for sustained resize events. Unfortunately we don't have a good solution yet.
`regedit` is particularly prone to this, because it takes a surprisingly long time to render its contents.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3909#note_52024