Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Splitting debugger in two - specific debugger and common GUI
ollydbg:
--- Quote from: MortenMacFly on January 31, 2012, 09:16:44 pm ---...so you see that due to the fact that some messages are strangely interrupted (WHY btw - I think this is a bug!!!) it does not really help. I get less messages, but still too much and still the debugger freezes after some time. Maybe a low-level filtering as suggested will help...
--- End quote ---
Does this code
--- Code: --- static wxString buffer;
buffer << output << _T('\n');
m_pDBG->DebugLog(output);
--- End code ---
In the function void GDB_driver::ParseOutput(const wxString& output) cause this issue?
MortenMacFly:
--- Quote from: oBFusCATed on January 30, 2012, 06:07:58 pm ---No, I've switched all my energy to gdb/mi plugin. The current plugin is lost battle. It works, but it will never be stable and fast.
--- End quote ---
BTW: I am not sure how far you are with the plugin, bus I have found a few interesting projects that provide a parser for the GDB/MI interface, like these:
* http://sourceforge.net/projects/shabe/ --> The GDB part is very small and nice, but only for GDB 7.1/7.2
* http://sourceforge.net/projects/libmigdb/ --> I guess you know this, but it seems dead
* http://sourceforge.net/projects/gdbshellwin/ --> A complete shell
* http://sourceforge.net/projects/ccdebug/ --> a complete front-end.,..maybe it is of help. But it seems to me that the MI is under development, and you need to take care about what version of GDB you are targeting...
oBFusCATed:
I've looked at libmigdb, but I decided to write my parser.
I have a working parser and stepping/breakpoints/watches should work.
The good thing about gdb/mi is that the communication protocol is stable. So you always parse the messages, but you might get new fields.
And this is not as problematic as the gdb/cli output, which changes more often.
Also compiling latest gdb is not that of a problem, as it turned out.
MortenMacFly:
Ok - here comes another issue... ;-)
- consider this code:
--- Code: ---#include <iostream>
void funca()
{
std::cout << "Hello!" << std::endl;
}
int main()
{
funca();
return 0;
}
--- End code ---
- place a BP at the line "funca();"
- continue to step through it with Next (F7)
- after a few times, everything comes to a halt.
You cannot stop/pause/continue/whats-over the debugger or C::B. You have to kill the debugger (not the debugee - that's impossible!) using the task manager.
Here is the debuggers debug log:
[debug](gdb) >>>>>>cb_gdb:
[debug]> show version
[debug]GNU gdb (GDB) 7.3
[debug]Copyright (C) 2011 Free Software Foundation, Inc.
[debug]License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
[debug]This is free software: you are free to change and redistribute it.
[debug]There is NO WARRANTY, to the extent permitted by law. Type "show copying"
[debug]and "show warranty" for details.
[debug]This GDB was configured as "mingw32".
[debug]For bug reporting instructions, please see:
[debug]<http://www.gnu.org/software/gdb/bugs/>.
[debug]>>>>>>cb_gdb:
[debug]> set confirm off
Debugger name and version: GNU gdb (GDB) 7.3
[debug]>>>>>>cb_gdb:
[debug]> set width 0
[debug]>>>>>>cb_gdb:
[debug]> set height 0
[debug]>>>>>>cb_gdb:
[debug]> set breakpoint pending on
[debug]>>>>>>cb_gdb:
[debug]> set print asm-demangle on
[debug]>>>>>>cb_gdb:
[debug]> set unwindonsignal on
[debug]>>>>>>cb_gdb:
[debug]> set print elements 0
[debug]>>>>>>cb_gdb:
[debug]> set debugevents on
[debug]>>>>>>cb_gdb:
[debug]> set new-console on
[debug]>>>>>>cb_gdb:
[debug]> set disassembly-flavor att
[debug]>>>>>>cb_gdb:
[debug]> catch throw
[debug]Catchpoint 1 (throw)
[debug]>>>>>>cb_gdb:
[debug]> source C:\Devel\CodeBlocks\src\devel29\share\codeblocks/scripts/stl-views-1.0.3.gdb
[debug]>>>>>>cb_gdb:
[debug]> directory C:/Users/morten/Desktop/MyCon/
[debug]>>>>>>cb_gdb:
[debug]> break "C:/Users/morten/Desktop/MyCon/main.cpp:10"
[debug]Breakpoint 2 at 0x401347: file C:\Users\morten\Desktop\MyCon\main.cpp, line 10.
[debug]>>>>>>cb_gdb:
[debug]> run
[debug]gdb: windows_init_thread_list
Child process PID: 7980
[debug][New Thread 7980.0x18c]
[debug]Breakpoint 2, main () at C:\Users\morten\Desktop\MyCon\main.cpp:10
[debug]c:\users\morten\desktop\mycon\main.cpp:10:101:beg:0x401347
[debug]>>>>>>cb_gdb:
At c:\users\morten\desktop\mycon\main.cpp:10
[debug]> set debugevents off
[debug]>>>>>>cb_gdb:
[debug]> next
[debug]c:\users\morten\desktop\mycon\main.cpp:11:115:beg:0x40134c
[debug]>>>>>>cb_gdb:
At c:\users\morten\desktop\mycon\main.cpp:11
[debug]> next
[debug]c:\users\morten\desktop\mycon\main.cpp:12:130:beg:0x401351
[debug]>>>>>>cb_gdb:
At c:\users\morten\desktop\mycon\main.cpp:12
[debug]> next
[debug]250 ../mingw/crt1.c: No such file or directory.
[debug]__mingw_CRTStartup () at ../mingw/crt1.c:250
[debug] in ../mingw/crt1.c
[debug]>>>>>>cb_gdb:
MortenMacFly:
--- Quote from: MortenMacFly on February 25, 2012, 03:42:51 pm ---Ok - here comes another issue... ;-)
--- End quote ---
...and another one:
From time to time I see this in the debuggers log when stepping through code using F7:
[debug]> next
[debug]Cannot find bounds of current function
[debug]>>>>>>cb_gdb:
After that, the debugger plugin is frozen and nothing happens until I kill the debugger (not the debugee - that's impossible!).
I didn't find a way to reproduce, not a minimal sample, but according to this:
http://bytes.com/topic/c/answers/786078-error-cannot-find-function-bounds
...the reason is a "buffer overrun problem somewhere in an inner function".
Nasty - but this should be handled correctly.
BTW: The sample to reproduce shown there does not reproduce this problem. :-(
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version