Hi, I'm coming from Windows, so a graphical debugging system is needed :-) I'm trying to connect winedbg to ddd as described in the docu, but the following error occured during startup: wine-pthread: gdbproxy.c:1984: extract_packets: Assertion 'i == gdbctx->out_len' failed. Same happens when I try to connect to kdbg... Any ideas? Thanks Markus Goemmel m.goemmel(a)compulab.de
Markus Gömmel wrote: > Hi, > > I'm coming from Windows, so a graphical debugging system is needed :-) > > I'm trying to connect winedbg to ddd as described in the docu, but the > following error occured during startup: > > wine-pthread: gdbproxy.c:1984: extract_packets: Assertion 'i == > gdbctx->out_len' failed. I didn't try ddd (I don't want to have Motif installed as well ;-) for kdbg, it works fine (except I get some quirks here): - be sure the specify on kdbg command line the wine real executable you're using (either wine-pthread or wine-kthread) - in kdbg, strangely enough the "Continue" item Execute menu doesn't work (IMO, it's a bug in kdbg as it's translated as a "run" command, while for a remote target it should be a 'continue' command). - hence, I suggest to set a breakpoint on pgm entry point (either WinMain or main), which isn't it at that time of execution, and then use solely the Execute item (F5) - in my case, the source code doesn't show up alone. I use the 'show code' button in the breakpoint window I'll update the doc with those items and I'll upgrade the output from winedbg so that one could get the full command line for kdbg startup without too much headache HTH -- Eric Pouech
Boaz Harrosh wrote:
Eric Pouech wrote:
- in my case, the source code doesn't show up alone. I use the 'show code' button in the breakpoint window
Is that gcc-elf-Linux code only like before? or is it possible now to, also see PE (.pdb) debugging info?
that didn't change. This would require gdb to know about .pdb, which it doesn't. in the long run, it may be easier to get windbg handle properly elf/{stabs|dwarf} information, rather than the other way around. A+ -- Eric Pouech
Eric Pouech wrote:
that didn't change. This would require gdb to know about .pdb, which it doesn't. in the long run, it may be easier to get windbg handle properly elf/{stabs|dwarf} information, rather than the other way around. A+
From passed experience, I have found that for Winelib, or Plain Wine debugging, I get the same results with Plain gdb. Or in my case KDevelop. (No need for Winedbg at all) For GUI .pdb debugging I have made some attempts to run Winedbg directly under KDevelop. As KDevelop Just pushes commands into gdb's stdin and in return parses stdout, With some relaxing of the parser code, I was able to get the stack frame and disassembly windows. This is do to the fact that Winedbg tries to keep the commands the same as gdb, and the output used to be similar as well. The more advanced stuff like setting breakpoints and watch variables failed miserably. But I was able to do those on the command prompt KDevelop provides as low level interface to "gdb". I was on my way to go in deeper and fix the C++ source debugging. Again by making the parser relax on the Winedbg output formating, but the Project canceled, and I never got to it. Since than Winedbg was completely changed, and I never attempted the same thing again. Free Life Boaz
For GUI .pdb debugging I have made some attempts to run Winedbg directly under KDevelop. As KDevelop Just pushes commands into gdb's stdin and in return parses stdout, With some relaxing of the parser code, I was able to get the stack frame and disassembly windows. This is do to the fact that Winedbg tries to keep the commands the same as gdb, and the output used to be similar as well. The more advanced stuff like setting breakpoints and watch variables failed miserably. But I was able to do those on the command prompt KDevelop provides as low level interface to "gdb". I was on my way to go in deeper and fix the C++ source debugging. Again by making the parser relax on the Winedbg output formating, but the Project canceled, and I never got to it. Since than Winedbg was completely changed, and I never attempted the same thing again.
in that case, it would be better IMO to make winedbg evolve so that its output and commands are the same as gdb, so you won't need to make each tool evolve to understand winedbg. A+ -- Eric Pouech
participants (3)
-
Boaz Harrosh -
Eric Pouech -
Markus G�mmel