Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
someone working on CDB debugger?
MortenMacFly:
--- Quote from: Martin K. on October 10, 2012, 09:33:47 pm ---Visual C++ 6 support
--- End quote ---
BTW, it has been some time I was using VS and the CDB debugger. It seems its now integrated in the Windows platform SDK but one can extract it easily from there. What version(s) are you using for your trials? One of these:
http://msdn.microsoft.com/en-us/windows/hardware/gg463041.aspx
???
It would be nice if you could clarify... especially, what's different to VC6? From my understanding, the CDB interface should be the same for debugging VC6 or any other VC version files, isn't it?
Martin K.:
--- Quote from: MortenMacFly on October 11, 2012, 09:20:38 am ---
--- Quote from: Martin K. on October 10, 2012, 09:33:47 pm ---Visual C++ 6 support
--- End quote ---
BTW, it has been some time I was using VS and the CDB debugger. It seems its now integrated in the Windows platform SDK but one can extract it easily from there. What version(s) are you using for your trials? One of these:
http://msdn.microsoft.com/en-us/windows/hardware/gg463041.aspx
???
It would be nice if you could clarify... especially, what's different to VC6? From my understanding, the CDB interface should be the same for debugging VC6 or any other VC version files, isn't it?
--- End quote ---
I am using CDB from different sources. I have one from the MSDN link above and one from the current WinDDK.
Generally, CDB handels all VC version the same way. I can use a 32 Bit CDB to debug every 32 Bit application build with a VC compiler and i can use the 64 Bit CDB to debug 32 and 64 bit applications. The difference between 32 and 64 Bit is the debugger prompt. The 64 Bit Debugger tells me at the prompt that my debuggee runs under the x86 environment.
The difference between the old VC6 compiler and never versions is the symbol table of the debuggee. The VS2010 compiler for example seems to use only absolute pathnames for the symbols (c:\project\test\main.c), the vc6 compiler uses relative paths (main.c) also and so the Debugger tells me different informations about source positions on a breakpoint hit.
Martin
MortenMacFly:
--- Quote from: Martin K. on October 11, 2012, 10:09:38 am ---also and so the Debugger tells me different informations about source positions on a breakpoint hit.
--- End quote ---
Too bad. Well think about how much time you invest in supporting this aged compiler than... it may not be worth it. I see more and more projects dropping support for this compiler already.
Martin K.:
OK,
one question to the debugger professionals:
Wich sense makes the function ShiftBreakpoint?
When the debuggee runs and there are breakpoints set, then an open editor windows calls this function for all breakpoints affected by a sourceline change (insert or delete lines). So it should move breakpoints to the new position. When i handle this function, the breakpoints view and the marker in the editor are moving too. Very nice. But the source ist out of sync with the symbol table of the debuggee. It makes no sense to send the new breakpoint position to the debugger (as the old Debugger_GDB does). And when i remember this changes internally in the breakpoint list, then i'm able to correct positions on debugger stops while hitting breakpoints. But i can't correct any position when the sourcecode changes while debugging without an breakpoint set, so this makes no sense to me. Any Ideas?
Martin
MortenMacFly:
--- Quote from: Martin K. on October 11, 2012, 02:11:24 pm ---Any Ideas?
--- End quote ---
Hopefully oBFusCATed can say something more detailed about this, but weren't there just with the last commits some changes accordingly to fix a (similar/same) wrong behaviour accordingly? Are your sources in sync with trunk?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version