Hi,
I'd like to improve debugging support for Wine, and have time to undertake a larger project. Either I could work on winedbg to match gdb's features, or I could try to make gdb understand Wine better. Given the amount of useful frontends for gdb, it seems wiser to go for the second option. I'd love to be corrected if you think working on winedbg is a better choice.
Gdb seems to have trouble understanding the way windows processes run in Wine. If anyone has thought about this, I'd like to know your opinions on a good solution to this problem.
Furthermore, it seems useful to make gdb parse the .pdb format, or other debugging information. Winedbg already has a working pdb parser, which I could port to gdb.
Feel free to push me in the right direction.
"Tijs" == Tijs van Bakel tijs@connectux.com writes:
...
Tijs> Furthermore, it seems useful to make gdb parse the .pdb format, or Tijs> other debugging information. Winedbg already has a working pdb Tijs> parser, which I could port to gdb.
Look also what has been done with gdb on windows ( cygwin, mingw). Some "gdb.exe" should use the same mechanismes like windows debuggers, which wine supports to some extend. If you get gdb to read the mostly undocumented new PDB format, this would be a big step. Being able to read wine's format dll.so would be a plus.
Bye
On Wednesday 22 May 2002 10:39 am, Tijs van Bakel wrote:
Either I could work on winedbg to match gdb's features, or I could try to make gdb understand Wine better. Given the amount of useful frontends for gdb, it seems wiser to go for the second option.
gdb can debug Windows programs compiled with Cygwin or mingw if you compile gdb with support for PE executables (I expect you know that already).
More details: http://groups.google.com/groups?hl=en&lr=&selm=6xUt8.14322%24sL6.203...
I wouldn't mind knowing what people think of the technique. I was wondering whether to suggest over at Debian that gdb be compiled this way by default. I don't know whether that's a good idea or whether things could be done better differently. It's possible to get it to work with RSXNTDJ progs too actually.
And I think you're right, it's a pretty nice way to work. You can use the mingw GNU/Linux to Windows cross compiler plus gdb, and then you can use your usual development environment for working on Windows programs.
So the work of the Cygwin and mingw projects helps Wine, and conversely any work you and the others who are already working on this do on supporting MS debugging formats then that could be used in the cygwin/mingw project's gdb.exe (presumably).
On Thu, May 23, 2002 at 01:28:38AM +0100, Michael Wetherell wrote:
On Wednesday 22 May 2002 10:39 am, Tijs van Bakel wrote:
Either I could work on winedbg to match gdb's features, or I could try to make gdb understand Wine better. Given the amount of useful frontends for gdb, it seems wiser to go for the second option.
gdb can debug Windows programs compiled with Cygwin or mingw if you compile gdb with support for PE executables (I expect you know that already).
More details: http://groups.google.com/groups?hl=en&lr=&selm=6xUt8.14322%24sL6.203...
I wouldn't mind knowing what people think of the technique. I was wondering
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?
Michael Cardenas wrote:
On Thu, May 23, 2002 at 01:28:38AM +0100, Michael Wetherell wrote:
On Wednesday 22 May 2002 10:39 am, Tijs van Bakel wrote:
Either I could work on winedbg to match gdb's features, or I could try to make gdb understand Wine better. Given the amount of useful frontends for gdb, it seems wiser to go for the second option.
gdb can debug Windows programs compiled with Cygwin or mingw if you compile gdb with support for PE executables (I expect you know that already).
More details: http://groups.google.com/groups?hl=en&lr=&selm=6xUt8.14322%24sL6.203...
I wouldn't mind knowing what people think of the technique. I was wondering
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?
What about writing a backend support for DDD and winedbg?
What about writing a backend support for DDD and winedbg?
as I previously wrote, I have gdb working with wine (with win32 threads, ELF files/modules support) I never tried ddd with that but it should work rather easily writing a back-end for DDD would either mean: - compile DDD as a winelib app (and write the back end with Win32 debugging API) - use a remote protocol (ddd as a unix process on one side communicating with a winelib app using the Win32 Api) (which is what I've started with gdb)
A+
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').
Michael Cardenas wrote:
Ont major problem is that gdb doesn't understand wine's handling of windows threads, even if it does understand the windows pe format.
It would appear I was a little too pessimistic here; while gdb does indeed not understand win32 threads directy, when using the remote debugging stub API, it looks like it is possible for the stub to tell gdb everything it needs to know about threads.
That would mean that it should be possible to write a remote debugging stub that uses the Win32 API to inform gdb about everything related to win32 threads ...
Ulrich, you want to post your presentation here?
Didn't you want to put those up on your website? It's probably a bit large for the list ...
Bye, Ulrich
-
Eric Pouech -
Michael Cardenas -
Michael Wetherell -
Shachar Shemesh -
tijs＠connectux.com -
Ulrich Weigand -
Uwe Bonnes