Hi, Trying to use the --gdb flag with winedbg does not work with 32-bit WINEPREFIXes. Instead of spawning gdb, it just exits: user@host:~$ WINEPREFIX=~/.wine32 winedbg --gdb notepad.exe 002a:002b: create process 'C:\windows\system32\notepad.exe' /0x1106b0 @0x7fa07e50 (0<0>) 002a:002b: create thread I @0x7fa07e50 user@host:~$ Running the same command with a 64-bit prefix works as expected: user@host:~$ winedbg --gdb notepad.exe 002b:002c: create process 'C:\windows\system32\notepad.exe'/0x10980 @0x7f8993d81b60 (0<0>) 002b:002c: create thread I @0x7f8993d81b60 GNU gdb (Debian 8.2.1-2+b3) 8.2.1 <snip> 002b:002c: loads DLL C:\windows\system32\uxtheme.dll @0x7f8990940000 (0<0>) warning: remote target does not support file transfer, attempting to access files from local filesystem. 0x000000007bc961e5 in DbgBreakPoint () from /usr/lib/wine/../x86_64-linux-gnu/wine/ntdll.dll.so Wine-gdb> I was able to reproduce the issue on a VM running only bullseye i386 (no foreign architectures), so it doesn't appear to be a multi-arch related issue. Also, the upstream packages work as expected on bullseye i386. I haven't tested them on buster. Tested, not working: ------------------- Buster, amd64, wine 4.0-2 from buster repo, 32-bit WINEPREFIX Bullseye, i386, wine 5.0-4 from bullseye repo, 32-bit WINEPREFIX Tested, working as expected: --------------------------- Buster, amd64, wine 4.0-2 from buster repo, 64-bit WINEPREFIX Bullseye, i386, winehq-stable 4.0.2~bullseye from winehq repo, 32-bit WINEPREFIX Bullseye, i386, winehq-stable 5.0.2~bullseye from winehq repo, 32-bit WINEPREFIX Bullseye, i386, winehq-devel 5.18~bullseye from winehq repo, 32-bit WINEPREFIX Best regards, Bill
Dear Maintainer, tried to have a look at it and found that this might be caused by the wine binary being pointed to by Debians alternatives system. Therefore winedbg does not find the loader shared object of the target process and cannot map it (elf_read_wine_loader_dbg_info). That module would be marked as "<wine-loader>" and 'winedbg --gdb' relies on finding that in function mod_loader_cb. If it cannot be found windbg exits directly after dbg_get_debuggee_info [1], unfortunately without any message. This can be worked around by setting the path before like in [2]. Because upstream changed winedbg since 5.6 to not rely on knowing the loader, I guess a "debianized" wine package from that version upwards should also not show this issue. [3] Kind regards, Bernhard [1] Breakpoint 7, mod_loader_cb (mod_name=<optimized out>, base=<error reading variable: Could not find the frame base for "mod_loader_cb".>, ctx=<error reading variable: Could not find the frame base for "mod_loader_cb".>) at winedbg.c:429 429 if (!strcmp(mod_name, "<wine-loader>")) 1: x/i $pc => 0x7fa056f4 <mod_loader_cb+36>: mov $0xe,%ecx (rr) bt #0 mod_loader_cb (mod_name=<optimized out>, base=<error reading variable: Could not find the frame base for "mod_loader_cb".>, ctx=<error reading variable: Could not find the frame base for "mod_loader_cb".>) at winedbg.c:429 #1 0x7f978bc5 in enum_modW64_64 (name=0x139ef8, base=2141257728, user=0x32f140) at module.c:805 #2 0x7f97aa79 in SymEnumerateModulesW64 (hProcess=<optimized out>, EnumModulesCallback=<optimized out>, UserContext=<optimized out>) at module.c:838 #3 0x7f97ab66 in SymEnumerateModules64 (hProcess=0x2c, EnumModulesCallback=0x7fa056d0 <mod_loader_cb>, UserContext=0x32f294) at module.c:817 #4 0x7fa06284 in dbg_get_debuggee_info (hProcess=<error reading variable: Could not find the frame base for "dbg_get_debuggee_info".>, imh_mod=<error reading variable: Could not find the frame base for "dbg_get_debuggee_info".>) at winedbg.c:452 #5 0x7f9f5724 in gdb_remote (flags=<optimized out>, port=<optimized out>) at gdbproxy.c:1930 #6 0x7f9f7cc3 in gdb_main (argc=<optimized out>, argv=<optimized out>) at gdbproxy.c:2110 #7 0x7f9e75e1 in main () from /usr/lib/wine/../i386-linux-gnu/wine/winedbg.exe.so #8 0x7fa0c8cd in __wine_spec_exe_entry (peb=<optimized out>) at exe_entry.c:64 #9 0x7b454882 in call_process_entry () from /usr/lib/wine/../i386-linux-gnu/wine/kernel32.dll.so #10 0x7b454cfc in start_process (entry=<optimized out>, peb=<optimized out>) at process.c:153 #11 0x7b45488e in __wine_start_process () from /usr/lib/wine/../i386-linux-gnu/wine/kernel32.dll.so #12 0x00000000 in ?? () [2] export PATH=/usr/lib/wine:$PATH wine winedbg --gdb notepad [3] https://source.winehq.org/git/wine.git/patch/86ed5e563dc75bc5dae30f9647eefa63efb132d5
Hi Bernhard, Thanks very much for investigating this! I can confirm that adjusting the PATH works around the issue for me. Best regards, Bill
version: 6.0+repack-1