I'm trying to debug a windows .exe built with mingw using wine, but winedbg seems to have problems reading stabs from the mingw-built binary. My goal is to be able to debug a cross-compiled, native Java (GCJ) application, but even a simple C "hello world" seems to cause problems.
My cross-build environment consists of:
- mingw-runtime-3.5 and w32api-3.1from mingw.org - I just used the pre-built binaries - stock binutils 2.15, configured with --target=mingw32 - CVS head gcc 4.0, configured with --target=mingw32
WINE is wine-0.20040914-1.rhfc2.nr from newrpms.sunsite.dk
$ mingw32-gcc hello.c -o hello-mingw.exe -g
$ wine ./hello-mingw.exe Hello World
$ winedbg --gdb ./hello-mingw.exe 0000000a:0000000b: create process 'D:\tests\hello-mingw.exe'/0x77bd003c @00401220 (0<0>) wine: Unhandled exception (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0xb6e4d174 in 32-bit code (0x657997a3). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:657997a3 ESP:5b56bc7c EBP:5b56ed78 EFLAGS:00210246( - 00 -RIZP1) EAX:b6e4d174 EBX:151409b8 ECX:00000000 EDX:261955dc ESI:00000000 EDI:b6e4d174 Stack dump: 0x5b56bc7c: 15135de8 b6e4d174 00000002 00010000 0x5b56bc8c: 00000000 00000000 00000000 00000000 0x5b56bc9c: 00000000 00000000 00000000 5b56cd6c 0x5b56bcac: 00000001 00000000 00000000 00000000 0x5b56bcbc: ffffffff ffffffff 00000000 7fc07000 0x5b56bccc: 7fc06000 00010000 7f980078 000000d5 Backtrace: =>1 0x657997a3 (0x5b56ed78) 2 0x15132ec0 (0x5b56edc8) 3 0x1513371c pe_load_debug_info+0x16c in dbghelp (0x5b56ee04) 4 0x1513391a pe_load_module+0x1ba in dbghelp (0x5b56ef54) 5 0x1512d93e SymLoadModule+0x9e in dbghelp (0x5b56ef94) 6 0x15129fd3 (0x5b56f4d8) 7 0x1512a129 SymInitialize+0x119 in dbghelp (0x5b56f518) 8 0x6101906a (0x5b56f650) 9 0x6101cfba (0x5b56f8e4) 10 0x6101d39a (0x5b56f970) 11 0x6101d422 gdb_remote+0x32 in winedbg (0x5b56fe44) 12 0x610279ec main+0x11c in winedbg (0x5b56fe90) 13 0x610122f1 (0x5b56ff20) 14 0x4824e0e2 (0x5b56fff4) 15 0x43940f31 (0x00000000) ....
I've attached the mingw-compiled C binary. Is it worth trying again with a newwer WINE? Thanks!
Bryce
On Sat, 2005-01-01 at 17:53 -0500, Bryce McKinlay wrote:
WINE is wine-0.20040914-1.rhfc2.nr from newrpms.sunsite.dk
Did you try the newer rpms on Wine's download page? One was probably built for the same setup you're using.
I've attached the mingw-compiled C binary. Is it worth trying again with a newwer WINE? Thanks!
Always!
-Scott Ritchie
On Sat, 2005-01-01 at 18:04 -0800, Scott Ritchie wrote:
On Sat, 2005-01-01 at 17:53 -0500, Bryce McKinlay wrote:
I've attached the mingw-compiled C binary. Is it worth trying again with a newwer WINE? Thanks!
Always!
-Scott Ritchie
Wait, I need to correct myself:
NOT ALWAYS.
There was a horrible bug in winelib that prevents compiling anything in the last release. Heh, sorry. For now I recommend either CVS or waiting for a week or two for the next release.
And, uh, I also recommend we go to a stable release system sooner rather than later :)
-Scott
Scott Ritchie wrote:
On Sat, 2005-01-01 at 18:04 -0800, Scott Ritchie wrote:
On Sat, 2005-01-01 at 17:53 -0500, Bryce McKinlay wrote:
I've attached the mingw-compiled C binary. Is it worth trying again with a newwer WINE? Thanks!
Wait, I need to correct myself:
NOT ALWAYS.
There was a horrible bug in winelib that prevents compiling anything in the last release. Heh, sorry. For now I recommend either CVS or waiting for a week or two for the next release.
Hi Scott.
I'm not actually using winelib (I think), but rather using a mingw-targeted cross-gcc to build "real" windows .exe's, and run those under wine. Now that you mention it, it might be worth giving winelib a try, however, as it might solve some of my testing/debugging issues. But, in this case, I'm attempting to test and debug a non-ELF binary - ie set up a debugging enviroment for actual windows exe's without actually having to run windows :)
In any case, I tried updating to wine-20041201-1fc2winehq.i686.rpm as you suggested. winedbg doesn't crash any more, at least on my small C test application, but it does show some stabs errors:
$ winedbg ./hello-mingw.exe WineDbg starting on pid 0xa In 32 bit mode. 0x0021647e: jmp 0x0021646d Wine-dbg>b main err:dbghelp_stabs:stabs_parse Unknown stab type 0x2e err:dbghelp_stabs:stabs_parse Unknown stab type 0x4e Many symbols with name 'main', choose the one you want (<cr> to abort): [1]: 0x004012a5 main+0x25 [/home/mckinlay/tests/hello.c:4] in hello-mingw [2]: 0x77f01130 main in <wine-loader> ...
On my much larger Java applications (larger because it is statically linked to the rather large libgcj runtime), I get thousands of those errors, followed (after a few minutes) by an Exception:
... err:dbghelp_stabs:stabs_parse Unknown stab type 0x2e err:dbghelp_stabs:stabs_parse Unknown stab type 0x4e
Exception c0000005 Wine-dbg>
Also, the "--gdb" mode doesn't seem to work as I'd expect in either case. I get a lot of "no debugging symbols found" errors from gdb in addition to the "Unknown stab type" errors as above.
$ winedbg --gdb ./hello-mingw.exe 0000000a:0000000b: create process 'D:\tests\hello-mingw.exe'/0x77bd003c @00401220 (0<0>) err:dbghelp_stabs:stabs_parse Unknown stab type 0x2e err:dbghelp_stabs:stabs_parse Unknown stab type 0x4e 0000000a:0000000b: create thread I @00401220 GNU gdb 6.3.50_2004-11-04-cvs ... (no debugging symbols found) trace: 98 => 80 Wine-gdb> b main Breakpoint 1 at 0x77f01148 Wine-gdb> c Continuing.
Program exited normally.
ie: gdb doesn't seem to be seeing the symbols from the windows .exe file.
Thanks for the help.
Bryce
Bryce McKinlay a écrit :
I'm trying to debug a windows .exe built with mingw using wine, but winedbg seems to have problems reading stabs from the mingw-built binary. My goal is to be able to debug a cross-compiled, native Java (GCJ) application, but even a simple C "hello world" seems to cause problems.
winedbg using the gdb won't work here because (likely on unix) gdb isn't compiled with proper 'stabs in PE' support
you can either: - use bare winedbg (without gdb support) - recompile gdb with 'stabs in PE' support (ie the settings used when compiling gdb under windows)
I tried your exe with latest cvs and it load just fine in winedbg (with and without gdb support)
I don't know what the unknown stabs type are for. They aren't defined in latest gdb (6.3), the only trace I found was for the MacOS/X but I doubt it concerns your case.
A+
On Sun, Jan 02, 2005 at 11:35:07AM +0100, Eric Pouech wrote:
winedbg using the gdb won't work here because (likely on unix) gdb isn't compiled with proper 'stabs in PE' support
Maybe we should lobby people (like Fedora) to enable it by default.
Dimitrie O. Paun a écrit :
On Sun, Jan 02, 2005 at 11:35:07AM +0100, Eric Pouech wrote:
winedbg using the gdb won't work here because (likely on unix) gdb isn't compiled with proper 'stabs in PE' support
Maybe we should lobby people (like Fedora) to enable it by default.
but this would require teaching gdb to use winelib too A+
Eric Pouech wrote:
Bryce McKinlay a écrit :
I'm trying to debug a windows .exe built with mingw using wine, but winedbg seems to have problems reading stabs from the mingw-built binary. My goal is to be able to debug a cross-compiled, native Java (GCJ) application, but even a simple C "hello world" seems to cause problems.
winedbg using the gdb won't work here because (likely on unix) gdb isn't compiled with proper 'stabs in PE' support
you can either:
- use bare winedbg (without gdb support)
- recompile gdb with 'stabs in PE' support (ie the settings used when
compiling gdb under windows)
Could you give any hints as to how to configure GDB with 'stabs in PE' support? The only reference I could find in the GDB documentation is:
"6.4.5 PE
Windows 95 and NT use the PE (/Portable Executable/) format for their executables. PE is basically COFF with additional headers.
While BFD includes special PE support, GDB needs only the basic COFF reader."
Is there a configure option to enable this support in the standard BFD/GDB code? (I'm using GDB from CVS head) - or are special patches required? How did you get/build the GDB you use?
Thanks!
Bryce
Bryce McKinlay a écrit :
Eric Pouech wrote:
Bryce McKinlay a écrit :
I'm trying to debug a windows .exe built with mingw using wine, but winedbg seems to have problems reading stabs from the mingw-built binary. My goal is to be able to debug a cross-compiled, native Java (GCJ) application, but even a simple C "hello world" seems to cause problems.
winedbg using the gdb won't work here because (likely on unix) gdb isn't compiled with proper 'stabs in PE' support
you can either:
- use bare winedbg (without gdb support)
- recompile gdb with 'stabs in PE' support (ie the settings used when
compiling gdb under windows)
Could you give any hints as to how to configure GDB with 'stabs in PE' support? The only reference I could find in the GDB documentation is:
"6.4.5 PE
Windows 95 and NT use the PE (/Portable Executable/) format for their executables. PE is basically COFF with additional headers.
While BFD includes special PE support, GDB needs only the basic COFF reader."
Is there a configure option to enable this support in the standard BFD/GDB code? (I'm using GDB from CVS head) - or are special patches required? How did you get/build the GDB you use?
There's no such things (and it's definitively not an easy task, which still remains to be done, and that Wine decided not to implement some years ago).
A+
Eric Pouech wrote:
Could you give any hints as to how to configure GDB with 'stabs in PE' support? The only reference I could find in the GDB documentation is:
"6.4.5 PE
Windows 95 and NT use the PE (/Portable Executable/) format for their executables. PE is basically COFF with additional headers.
While BFD includes special PE support, GDB needs only the basic COFF reader."
Is there a configure option to enable this support in the standard BFD/GDB code? (I'm using GDB from CVS head) - or are special patches required? How did you get/build the GDB you use?
There's no such things (and it's definitively not an easy task, which still remains to be done, and that Wine decided not to implement some years ago).
In that case, what is "winedbg --gdb" for? Why have this option if no GDB supports it?
Bryce
In that case, what is "winedbg --gdb" for? Why have this option if no GDB supports it?
because it targets different stuff:
winedbg (standalone) is able to load and use debug info from: - ELF modules (exec and shared libs) (with stabs info, dwarf2 isn't supported). As wine DLLs are implemented on top of ELF shared libs, this also includes wine builtin DLLs (Wine forces stabs as its debug info, even on newest version of gcc where dwarf2 is the default) - PE modules (native Win32 compilation), compiled with either MSVC or Mingw. Note that Mingw stores its debug information as stabs (same as ELF), but the way to get to the stabs information from an ELF or a PE module is different (as this information is referenced from the ELF (resp. PE) headers)
gdb on Linux (it's also what you get with winedbg --gdb) is able (out of the box) to handle the ELF modules as explained above (it also handles dwarf2, with can be handy in some cases), but doesn't know on how to get stabs info from PE modules even if it knows how to handle stabs debug format.
However, Mingw port of gdb on Win32 includes this support. Maybe Mingw's gdb port might be an alternative for you (but 1/ I never tested it, so it may even not work, 2/ won't give you access to debug information for the ELF modules).
A+
-
Bryce McKinlay -
Dimitrie O. Paun -
Eric Pouech -
Scott Ritchie