I've started looking at this. I already have up & running (even if everything is not perfect) an implementation of the gdb remote target in winedbg. Basically, this allows the following scheme: gdb <gdb remote protocol> winedbg <Win32 debug API> wineserver
winedbg is in this case just a proxy between the gdb remote protocol and the Win32 debug API.
This works quite well, with decent performance (even using the remote protocol). However, this doesn't support the standard Windows debug formats (as winedbg does). I've also started looking at the way to integrate this into gdb, but it still requires lots of work before being operational.
in terms of porting options for gdb, I've looked at several options to do the job, what has to be done. (I'll format tonight the result of the analysis, when I'm back home)
A+
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 van Bakel, ConnecTUX, tijs@connectux.com
--------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle
____________________________________________________________ Faites un voeu et puis Voila ! www.voila.fr Avec Voila Mail, consultez vos e-mails sur votre mobile Wap.
Eric Pouech a écrit :
in terms of porting options for gdb, I've looked at several options to do the job, what has to be done. (I'll format tonight the result of the analysis, when I'm back home)
as said, you'll find here a more detailed analysis of the gdb and wine integration http://perso.wanadoo.fr/eric.pouech/wine_and_gdb.html
I considered 4 options for the debugger: - keeping on working on WineDbg - using GDB, but as a native Linux application. From a technical point of view, the debugger only interacts with the Unix APIs. - using GDB, but as a WineLib application. In this case, the debugger would use the Win32 debugging API. - using GDB remote protocol (with GDB still a native application, and a remote stub being a winelib application). GDB will use the remote protocol, and the remote stub will convert the gdb remote protocol request into Win32 calls.
I crossed those options with several features needed for the Wine debugger: Image formats (that the debugger understands) (this includes both the image format in itself, and the debugging symbols) at least two families are required: - PE, with different types of symbols (PE bare: just the exported symbols, PE MSC & .DBG the standard MSC debug formats => in fact I could have merged those two lines into a single one), PE Cygwin (PE file format, with Stabs debug information) - ELF, with basic format (ELF bare) and the regular debug formats (stabs for GCC <= 3.0, and Dwarf which is now the standard for GCC 3.1) One of the points to understand here, is that the debugger shall be required (IMO) to automatically load the symbols of a DLL (or .so) when this one is loaded by the program. One hard work is to build a debugger which supports both of them at the same time. WineDbg does it, gdb doesn't (even if technical solutions can be found).
Platforms/CPU - we need to plan for extending the supported CPUs. So, I listed two of them, but once again, the real difference is i386 or something else
Power (what can be done with the debugger itself) - ability to add graphical tools (like a graphical debugger, or to integrate it into an existing IDE) - JIT: being able to fire the debugger when hitting a crash - manipulation of Win32 objects (semaphores, mutexes, threads, windows, heaps...)
Engineering (effort to put something up and to keep it in time)
From that matrix, it seemed to me that the best solution was to use the
GDB remote protocol and the proxy.
From a pure GDB point of view, what remains to be done:
1/ integrate the MSC, .DBG symbol loader (which already exists in Wine). This requires some work, as symbol loading in GDB is rather different. GDB implements a three phase loading for the symbols (just to speed up to loading speed). Symbols come into three flavors: - minimal: exported symbols from a module - partial: the global symbols of a module (without their types) - full: the partial symbols (plus their type) and all the local variables 2/ the module type recognition requires refinement. As of today, GDB is confused when a PE module is loaded. GDB thinks it's either a real PE module or an EFI module (GDB code isn't refined enough because those two module types are never compiled together). This should be fixed somehow. For now, removing efi support while compiling gdb is enough. 3/ automatic loading of debug information when a PE module is loaded. This has been done for the Cygwin port, but requires to use the Win32 debug API (read a winelib gdb) which IMO is a very hard task (in particular, in the maintenance area).
let me know if you need further information
A+
On Thu, May 23, 2002 at 09:26:52PM +0200, Eric Pouech wrote:
Eric Pouech a écrit :
in terms of porting options for gdb, I've looked at several options to do the job, what has to be done. (I'll format tonight the result of the analysis, when I'm back home)
as said, you'll find here a more detailed analysis of the gdb and wine integration http://perso.wanadoo.fr/eric.pouech/wine_and_gdb.html
I considered 4 options for the debugger:
- keeping on working on WineDbg
- using GDB, but as a native Linux application. From a technical point
of view, the debugger only interacts with the Unix APIs.
- using GDB, but as a WineLib application. In this case, the debugger
would use the Win32 debugging API.
- using GDB remote protocol (with GDB still a native application, and a
remote stub being a winelib application). GDB will use the remote protocol, and the remote stub will convert the gdb remote protocol request into Win32 calls.
I crossed those options with several features needed for the Wine debugger:
[...]
It seems you forgot to list one of the most important things: Win16 support via WOW interface.
Andreas Mohr a écrit :
On Thu, May 23, 2002 at 09:26:52PM +0200, Eric Pouech wrote:
Eric Pouech a écrit :
in terms of porting options for gdb, I've looked at several options to do the job, what has to be done. (I'll format tonight the result of the analysis, when I'm back home)
as said, you'll find here a more detailed analysis of the gdb and wine integration http://perso.wanadoo.fr/eric.pouech/wine_and_gdb.html
I considered 4 options for the debugger:
- keeping on working on WineDbg
- using GDB, but as a native Linux application. From a technical point
of view, the debugger only interacts with the Unix APIs.
- using GDB, but as a WineLib application. In this case, the debugger
would use the Win32 debugging API.
- using GDB remote protocol (with GDB still a native application, and a
remote stub being a winelib application). GDB will use the remote protocol, and the remote stub will convert the gdb remote protocol request into Win32 calls.
I crossed those options with several features needed for the Wine debugger:
[...]
It seems you forgot to list one of the most important things: Win16 support via WOW interface.
I'm not sure that this is so important... WineDbg support for 16 bit exec has been broken since the address space separation, and no one really complained... support as it is now for 16 bit app (ie single stepping in 16 bit code) is supported by all options. Loading symbols for 16 bit apps is supported by none (and likely to remain so) I didn't add the DOS (and DPMI) support either
A+
Eric Pouech eric.pouech@wanadoo.fr writes:
I'm not sure that this is so important... WineDbg support for 16 bit exec has been broken since the address space separation, and no one really complained... support as it is now for 16 bit app (ie single stepping in 16 bit code) is supported by all options.
Does gdb really support 16-bit pointers now? Otherwise I don't see how you can step through 16-bit code. And even if 16-bit binaries are not really important, support for 16-bit pointers definitely is.
Does gdb really support 16-bit pointers now? Otherwise I don't see how you can step through 16-bit code. And even if 16-bit binaries are not really important, support for 16-bit pointers definitely is.
I responded to fast. Of course, only the stepping thru wine's builtin 16 bit modules is available (but that's 32 bit code) For pointer deref, one quick solution is to add one command to gdb which converts a segmented pointer into a linear address. Then this linear address can be used in any gdb command (it'll much more harder to add segmented pointers support though out every expression)
A+
Eric Pouech eric.pouech@wanadoo.fr writes:
For pointer deref, one quick solution is to add one command to gdb which converts a segmented pointer into a linear address. Then this linear address can be used in any gdb command (it'll much more harder to add segmented pointers support though out every expression)
This would be pretty painful to use; and you'll need more than that to be able to step through code and see what you are doing. This is a big limitation of gdb, and it's the main reason we wrote the wine debugger in the first place.
This would be pretty painful to use; and you'll need more than that to be able to step through code and see what you are doing. This is a big limitation of gdb, and it's the main reason we wrote the wine debugger in the first place.
sure. OTOH, it's also a PITA to be able to maintain and enhance winedbg
We'll have to deal with (to name a few): - dwarf debug symbols - C++ ABI (if we want to provide a decent C++ environment for WineLib) - portability to other processors
I'm not pushing for eliminating WineDbg, but adding with minor cost a real support for gdb in wine would be rather neat. Unfortunately, there's no solution that'll meat all our expectations... but with two, we cover quite what we need
A+
-
Alexandre Julliard -
Andreas Mohr -
Eric Pouech -
Eric Pouech