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+
