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`
--
v13: 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.
tools: Add gdbunwind.py script with a syscall unwinder.
ntdll: Maintain a PE module link map and expose it to GDB.
loader: Expose a shadow copy of ld.so link map to GDB.
loader: Add rtld_init SystemTap probe to the preloader.
configure.ac: Check for systemtap sys/sdt.h header.
gitlab: Install systemtap-sdt-dev packages.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1074
> ```diff
> -#if defined(SONAME_LIBDXCOMPILER) && !defined(VKD3D_CROSSTEST)
> +#if defined(SONAME_LIBDXCOMPILER) || defined(VKD3D_CROSSTEST)
> ```
Should that just be "#if defined(SONAME_LIBDXCOMPILER)"? We could perhaps consider defining SONAME_LIBDXCOMPILER to "dxcompiler.dll" if it isn't already defined and we have VKD3D_CROSSTEST, but in principle I don't think VKD3D_CROSSTEST needs special handling here.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/519#note_55909