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.