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`
--
v14: 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.
DEBUG: ntdll: Don't use preloader when running on valgrind.
tools: Add gdbunwind.py script with a syscall unwinder.
ntdll: Maintain a PE module link map and expose it to GDB.
loader: Expose the standard debugging symbols for GDB.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1074
Follow up to !5342. This adds the last missing piece for fixing how `ShellExecute` finds files, and restore the ability of running native unix programs with `ShellExecute`
--
v6: shell32: Restore the ability of running native unix programs with ShellExecute
https://gitlab.winehq.org/wine/wine/-/merge_requests/5400
As an intermediate step on the way to !5388, I wanted to focus on the infrastructure that will allow us to pass pixel format information from the driver to the PE side. This MR introduces the mechanism to perform this information exchange and uses it to implement `wglDescribePixelFormat` on the PE side. In the current RFC state this MR:
1. Introduces `p_get_pixel_format` driver API to allow drivers to provide pixel format information.
2. Implements `wglDescribePixelFormat` on the PE side using the pixel format information. If the driver doesn't implement `p_get_pixel_format` we fall back to the `wglDescribePixelFormat` driver implementation (temporary measure until all drivers are updated).
3. Caches pixel format information in `NtCurrentTeb()->glReserved1[]`.
4. Implements `p_get_pixel_format` API and removes the custom `wglDescribePixelFormat` for winewayland.
At this point would like to get some more feedback about this approach and the technical details. If the direction seems promising, here are the next steps to get to a final MR:
1. Implement `p_get_pixel_format` for winex11, winemac and dibdrv and remove their custom `wglDescribePixelFormat` implementations.
2. Remove the `wglDescribePixelFormat` driver API.
Thanks!
--
v2: winex11.drv: Remove unnecessary parameter from describe_pixel_format.
winex11.drv: Enable wglDescribePixelFormat through p_get_pixel_formats.
winewayland.drv: Enable wglDescribePixelFormat through p_get_pixel_formats.
opengl32: Cache driver pixel format information.
opengl32: Implement wglDescribePixelFormat using new driver API get_pixel_formats.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5517
In source_reader_create_transform(), store the result of
IMFActivate_ActivateObject() so that in the event of failure, resources
are freed and an appropriate HRESULT is returned.
Previously, if every object's activation failed, the last part of the
function was not aware of this.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5515