WineDbg can act as a remote monitor for GDB. This allows to use all the power of GDB, but while debugging wine and/or any Win32 application. To enable this mode, just add --gdb to winedbg command line. You'll end up on a GDB prompt. You'll have to use the GDB commands (not the wine nes).
However, some limitation in GDB while debugging wine (see below) don't ppear in this mode:
GDB will correctly present Win32 thread information and breakpoint behavior
Moreover, it also provides support for the Dwarf II debug format (which became the default format (instead of stabs) in gcc 3.1).
A few wine extensions available through the monitor command.
monitor wnd lists all window in the Wine session
monitor proc lists all processes in the Wine session
monitor mem displays memory mapping of debugged process
(doesn't work) |
You can also use other debuggers (like gdb), but you must be aware of a few items:
You need to attach the unix debugger to the correct unix process (representing the correct windows thread) (you can "guess" it from a ps fax for example: When running the emulator, usually the first two upids are for the Windows' application running the desktop, the first thread of the application is generally the third upid; when running a Winelib program, the first thread of the application is generally the first upid)
Note: Even if latest gdb implements the notion of threads, it won't work with Wine because the thread abstraction used for implementing Windows' thread is not 100% mapped onto the linux posix threads implementation. It means that you'll have to spawn a different gdb session for each Windows' thread you wish to debug.
Following text written by Andreas Mohr <andi@rhlx01.fht-esslingen.de>
Here's how to get info about the current execution status of a certain Wine process:
Change into your Wine source dir and enter:
$ gdb wine
|
Switch to another console and enter ps ax | grep wine to find all wine processes. Inside gdb, repeat for all Wine processes:
(gdb) attach PID
|
with PID being the process ID of one of the Wine processes. Use
(gdb) bt
|
to get the backtrace of the current Wine process, i.e. the function call history. That way you can find out what the current process is doing right now. And then you can use several times:
(gdb) n
|
or maybe even
(gdb) b SomeFunction
|
and
(gdb) c
|
to set a breakpoint at a certain function and continue up to that function. Finally you can enter
(gdb) detach
|
to detach from the Wine process.
You can use any Windows' debugging API compliant debugger with Wine. Some reports have been made of success with VisualStudio debugger (in remote mode, only the hub runs in Wine). GoVest fully runs in Wine.
Table 2-1. Debuggers comparison
| WineDbg | gdb |
| WineDbg debugs a Windows' process: the various threads will be handled by the same WineDbg session, and a breakpoint will be triggered for any thread of the W-process | gdb debugs a Windows' thread: a separate gdb session is needed for each thread of a Windows' process and a breakpoint will be triggered only for the w-thread debugged |
| WineDbg supports debug information from stabs (standard Unix format) and Microsoft's C, CodeView, .DBG | GDB supports debug information from stabs (standard Unix format) and Dwarf II. |