On Saturday 01 Jun 2002 5:56 pm, Michael Cardenas wrote:
This was discussed at wineconf, well, getting gdb to work with wine was discussed at wineconf because of the huge value in having a graphical front end for debugging.
Ont major problem is that gdb doesn't understand wine's handling of windows threads, even if it does understand the windows pe format.
Ulrich Weigand gave a great presentation where he talked about how the debugger is currently implemented, and things that would need to be done to have more support from gdb.
Ulrich, you want to post your presentation here?
Well, I was trying to point out what people can do with gdb and wine as they are now really, and I think you can do some pretty useful things with it even on multithreaded programs. I wan't trying to suggest further work wouldn't be a good idea, and of course I hadn't heard about Eric Pouech's work on a winedbg stub for gdb when I wrote that either.
Like you say regular Unix gdb doesn't have any support for wine's threads, but as the gdb docs day 'there is a workaround which isn't too painful'. Another thing you don't get (aside from support for .PDBs, .DBGs, 16-bit code and JIT) is automatic loading of symbols.
For the symbols, you can create a gdb command file: $ cat syms set gnutarget pei-i386 add-symbol-file HelloWin.exe add-symbol-file HelloDll.dll
And you can do one too for starting up your program and breaking at WinMain: $ cat strt tbreak main r HelloWin.exe tbreak start_process c source syms tbreak WinMain c
Then you can debug your program like this: $ gdb -x strt wine same for ddd: $ ddd -x strt wine
To single step though the code of another thread, you could use the technique outlined the gdb manual for fork, or probably easier is to get the thread to invoke the debugger on itself by adding a line like this at the place you want to break:
WinExec("y:\bin\debugme", SW_NORMAL);
and create a script to lunch gdb (or ddd, etc): $ cat ~/bin/debugme #!/bin/sh echo Debugging wine process $PPID gdb -x syms wine $PPID
In the debugger get a backtrace and you'll see WinExec maybe 6 frames up the stack, so you'd type 'up 6' then 'finish' and from there you'll be stepping though your own code.
On my machine, at least, gdb attaches quickly enough for the thread to still be in WinExec, but not if I use a front end like ddd. Anyway if on your setup you find it's already moved on then just add a small delay such as 'Sleep(5000);' after the WinExec (then of course you'll be looking for 'Sleep' on the backtrace instead of 'WinExec').