[Bug 57308] New: Cannot load split debug symbols under /usr/lib/debug
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(a)winehq.org Reporter: pq2sx44teeigl7za(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57308 yan12125 <pq2sx44teeigl7za(a)chyen.cc> changed: What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |ArchLinux -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57308 swm <swm+wine(a)not-a.website> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |swm+wine(a)not-a.website -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57308 --- Comment #1 from Rafał Mużyło <galtgendo(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57308 Bernhard Übelacker <bernhardu(a)mailbox.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bernhardu(a)mailbox.org --- Comment #2 from Bernhard Übelacker <bernhardu(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57308 --- Comment #3 from Eric Pouech <eric.pouech(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57308 --- Comment #4 from yan12125 <pq2sx44teeigl7za(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57308 --- Comment #5 from yan12125 <pq2sx44teeigl7za(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57308 --- Comment #6 from Bernhard Übelacker <bernhardu(a)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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57308 --- Comment #7 from Bernhard Übelacker <bernhardu(a)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; -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57308 Eric Pouech <eric.pouech(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |eric.pouech(a)gmail.com --- Comment #8 from Eric Pouech <eric.pouech(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57308 --- Comment #9 from Eric Pouech <eric.pouech(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57308 --- Comment #10 from Eric Pouech <eric.pouech(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57308 Joel Holdsworth <joel(a)airwebreathe.org.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |joel(a)airwebreathe.org.uk -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57308 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, source -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57308 yan12125 <pq2sx44teeigl7za(a)chyen.cc> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #11 from yan12125 <pq2sx44teeigl7za(a)chyen.cc> --- It works after https://gitlab.winehq.org/wine/wine/-/merge_requests/6715 is merged. Thank you! -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57308 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #12 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 10.0-rc1. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla