https://bugs.winehq.org/show_bug.cgi?id=57308
Bug ID: 57308 Summary: Cannot load split debug symbols under /usr/lib/debug Product: Wine Version: 9.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: dbghelp Assignee: wine-bugs@winehq.org Reporter: pq2sx44teeigl7za@chyen.cc Distribution: ---
We're discussing splitting PE debug symbols into a separate Arch Linux package to reduce disk usage for users that don't need it: https://gitlab.archlinux.org/archlinux/packaging/packages/wine/-/issues/16. Typically, split debug symbol files are placed under /usr/lib/debug. Apparently, wine tries to find them but something wrong happens. If I run strace on the UNIX process for winedbg.exe, I got this when a crash happens in msvcrt.dll:
16423 newfstatat(AT_FDCWD, "/usr/lib/debug/\??\Z:\usr\lib\wine\x86_64-windows\msvcrt.dll.debug", 0x7ffffe0ff8e0, 0) = -1 ENOENT
The path should be /usr/lib/debug/usr/lib/wine/x86_64-windows/msvcrt.dll.debug. It seems Windows paths are not correctly converted to UNIX paths.
https://bugs.winehq.org/show_bug.cgi?id=57308
yan12125 pq2sx44teeigl7za@chyen.cc changed:
What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |ArchLinux
https://bugs.winehq.org/show_bug.cgi?id=57308
swm swm+wine@not-a.website changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |swm+wine@not-a.website
https://bugs.winehq.org/show_bug.cgi?id=57308
--- Comment #1 from Rafał Mużyło galtgendo@o2.pl --- ...yeah, about that: on Linux that usually works though an ELF tag; libs under x86_64-windows are cross-compiled Windows DLLs - those use different mechanism and I wouldn't be surprised if - if anything like that is even possible (it might be) - the files with symbols needed to be in the same path as their libs, perhaps even mandatorily in pdb format.
:shrug: Gentoo skips stripping dlls, only doing it with ELF libraries.
https://bugs.winehq.org/show_bug.cgi?id=57308
Bernhard Übelacker bernhardu@mailbox.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bernhardu@mailbox.org
--- Comment #2 from Bernhard Übelacker bernhardu@mailbox.org --- (In reply to Rafał Mużyło from comment #1)
...yeah, about that: on Linux that usually works though an ELF tag; libs under x86_64-windows are cross-compiled Windows DLLs - those use different mechanism and I wouldn't be surprised if - if anything like that is even possible (it might be) - the files with symbols needed to be in the same path as their libs, perhaps even mandatorily in pdb format.
:shrug: Gentoo skips stripping dlls, only doing it with ELF libraries.
I guess in this context an example could be Cygwin, as it looks like it provides stripped PEs, and separate debug symbols, without using PDBs:
https://ftp-stud.hs-esslingen.de/pub/Mirrors/sources.redhat.com/cygwin/x86_6... - usr/bin/ls.exe ls.exe: PE32+ executable (console) x86-64, for MS Windows, 12 sections
https://ftp-stud.hs-esslingen.de/pub/Mirrors/sources.redhat.com/cygwin/x86_6... - usr/lib/debug/usr/bin/ls.exe.dbg ls.exe.dbg: PE32+ executable (console) x86-64, for MS Windows, 21 sections
But I guess due to the connected archlinux issue this wine bug is not about splitting the debug info, instead really about winedbg searching with a strange path?
If I read it right a start for some experimenting could be to create a single split dll by: - copy dll to dll.debug and "objcopy --only-keep-debug" on it - strip the original dll
https://bugs.winehq.org/show_bug.cgi?id=57308
--- Comment #3 from Eric Pouech eric.pouech@gmail.com --- for packaging, one could use: <wine-src>/configure --prefix=<...> [omitting arch info] CROSSDEBUG=splitdwarf
that would generate all the cross compiled modules (.dll, .exe) with split debug info (in their own foo.dll.debug file)
then these files will have a .gnu_debuglink section (a PE section, not an ELF one, but the meaning and content is exactly the same), These .debug files could be installed (as ELF ones) according to .build-id hierarchy in /usr/lib/debug.
Note: wine debugger is able to search the .debug file in user's debuginfod directory, but isn't capable (yet) to download them upon need.
HTH
https://bugs.winehq.org/show_bug.cgi?id=57308
--- Comment #4 from yan12125 pq2sx44teeigl7za@chyen.cc --- Thank you for the details. I did use objcopy to generate foo.dll.debug files. However, I didn't find a way for this part:
These .debug files could be installed (as ELF ones) according to .build-id hierarchy in /usr/lib/debug.
Specifically, I didn't find a command to parse the build ID for PE files, so I put debug files to /usr/lib/debug/usr/lib/wine/x86_64-windows/foo.dll.debug. It seems wine attempts paths with that pattern, but not doing it correctly.
https://bugs.winehq.org/show_bug.cgi?id=57308
--- Comment #5 from yan12125 pq2sx44teeigl7za@chyen.cc --- As a side note, I run objcopy manually instead of using CROSSDEBUG as the latter does not integrate with makepkg (the script for building Arch Linux packages) well. More details can be found in my WIP branch https://gitlab.archlinux.org/yan12125/pacman/-/commits/pe-symbols
https://bugs.winehq.org/show_bug.cgi?id=57308
--- Comment #6 from Bernhard Übelacker bernhardu@mailbox.org --- For having a buildid inside the PE files the configure option `--enable-build-id` seems to be relevant.
One method to retrieve this buildid might be this: x86_64-w64-mingw32-objcopy --output-target=binary \ --only-section=.buildid notepad-test.exe \ /dev/stdout | xxd -plain -seek 28 -l 20
Unfortunately I still have not observed an attempt of winedbg to use it with `get_dos_file_name("/usr/lib/debug/.build-id/...") for the PE exe.
Also I wonder if a call to image_check_debug_link_crc with somethign like "/usr/lib/debug/\??\Z:\path\to\notepad.exe.debug" is supposed to work?
Because of the `lstrcpyW(p, module->real_path);` in dlls/dbghelp/module.c:624 there appears this `\??\` between the globaldebugdir and the wine path. Without this `get_dos_file_name` would probably be able to construct a valid "$WINEPREFIX/dosdevices/z:/usr/lib/debug/.build-id/..." path?
https://bugs.winehq.org/show_bug.cgi?id=57308
--- Comment #7 from Bernhard Übelacker bernhardu@mailbox.org --- My comment 6 is wrong, as there the output contains always 52534453 / "RSDS", and seems part of a singature:
With a notepad.exe configured with plain `--enable-build-id`: llvm-readobj-14 --coff-debug-directory notepad.exe ... PDBSignature: 0x53445352 PDBGUID: (0C ED DF EF 5F 62 3C 69 FC 6B 7E D7 5F A9 D3 26) ...
Therefore a more correct version of comment 6 would be: x86_64-w64-mingw32-objcopy --output-target=binary \ --only-section=.buildid notepad.exe \ /dev/stdout | xxd -plain -seek 32 -l 16
Unfortunatley a test with `CROSSLDFLAGS=-Wl,--build-id=sha1` instead of the `--enable-build-id` did also just add a 16 bytes ".buildid" hash.
But it looks like dbghelp.dll ignores currently the ".buildid" section instead searches for a ".note.gnu.build-id" section.
Therefore I guess currently just the search via filename would work, if the globaldebugdir lookup would be modified like this:
dlls/dbghelp/module.c @@ static struct image_file_map* image_locate_debug_link lstrcpyW(p, module->real_path); + if (!_wcsnicmp(p, L"\??\Z:\", 7)) + memmove(p, p + 7, (wcslen(p) + 1 - 7) * sizeof(WCHAR)); slash = p;
https://bugs.winehq.org/show_bug.cgi?id=57308
Eric Pouech eric.pouech@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |eric.pouech@gmail.com
--- Comment #8 from Eric Pouech eric.pouech@gmail.com --- (In reply to yan12125 from comment #5)
As a side note, I run objcopy manually instead of using CROSSDEBUG as the latter does not integrate with makepkg (the script for building Arch Linux packages) well. More details can be found in my WIP branch https://gitlab.archlinux.org/yan12125/pacman/-/commits/pe-symbols
the preferred way to handle distributing split debug symbols for PE file would be to: On Arch side: - configure with --enable-build-id option - adapt the script as proposed in #5 with; + build id can be extracted with: objdump -p dlls/aclui/x86_64-windows/aclui.dll | \ sed -n "/RSDS signature / {s/.*signature //; s/ age.*//p; q;}" (you may have to use the mingw's objdump depending on compilation options of objdump) + using the same hierarchy to store .debug files as ELF (no need for a separate one)
On Wine side: - need to adapt dbghelp to handle correctly the .builid section
https://bugs.winehq.org/show_bug.cgi?id=57308
--- Comment #9 from Eric Pouech eric.pouech@gmail.com ---
Therefore I guess currently just the search via filename would work, if the globaldebugdir lookup would be modified like this:
dlls/dbghelp/module.c @@ static struct image_file_map* image_locate_debug_link lstrcpyW(p, module->real_path);
if (!_wcsnicmp(p, L"\\??\\Z:\\", 7))memmove(p, p + 7, (wcslen(p) + 1 - 7) * sizeof(WCHAR)); slash = p;
I think we'd rather move to binding debug symbol by build id as: - unless they are stored in same directory as images, other debugger won't be able to get them - if we want to use (whatever the debugger) automatic debug symbol download, then a buildid is the way to go
https://bugs.winehq.org/show_bug.cgi?id=57308
--- Comment #10 from Eric Pouech eric.pouech@gmail.com --- I've just pushed https://gitlab.winehq.org/wine/wine/-/merge_requests/6715 that should cover most of the elements needed on Wine side.
The MR contains a bit more precise bits about what's should be done on distro side as well. So please rather consider the MR content as more accurate than what's written in this bug report.
Feed back welcomed.
https://bugs.winehq.org/show_bug.cgi?id=57308
Joel Holdsworth joel@airwebreathe.org.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |joel@airwebreathe.org.uk
https://bugs.winehq.org/show_bug.cgi?id=57308
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, source
https://bugs.winehq.org/show_bug.cgi?id=57308
yan12125 pq2sx44teeigl7za@chyen.cc changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
--- Comment #11 from yan12125 pq2sx44teeigl7za@chyen.cc --- It works after https://gitlab.winehq.org/wine/wine/-/merge_requests/6715 is merged. Thank you!
https://bugs.winehq.org/show_bug.cgi?id=57308
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #12 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 10.0-rc1.
-
WineHQ Bugzilla