Improving debugging (gdb) support

[Eric Pouech]

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)