Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Splitting debugger in two - specific debugger and common GUI
MortenMacFly:
--- Quote from: oBFusCATed on January 29, 2012, 05:37:27 pm ---You can try to set wxDEBUG_LEVEL==0 or provide a null assert handler.
--- End quote ---
Does not help and it shouldn't be an option at compile time anyways.
--- Quote from: oBFusCATed on January 29, 2012, 05:37:27 pm ---
--- Code: ---if (line[i].StartsWith(wxT("warning:"))
{
m_pDBG->Log(wxT("skipped:")+lines[i]);
}
--- End code ---
--- End quote ---
That would indeed be worth an option, but...
Meanwhile I found out, why this happens:
This GDB command:
set debugevents on
...should definitely be an option on GDB. Turning this feature off made all the messages go away. And that does make sense, because a lot applications "spit out" many of such debugging messages. But during a normal debugging session you don't always want to see them, e.g. when tracing a crash they are usually of no help.
MortenMacFly:
--- Quote from: MortenMacFly on January 29, 2012, 07:39:52 pm ---This GDB command:
set debugevents on
...should definitely be an option on GDB.
--- End quote ---
BTW: I am thinking, why not putting all of these GDB initialisation commands:
[debug]> set confirm off
[debug]> set width 0
[debug]> set height 0
[debug]> set breakpoint pending on
[debug]> set print asm-demangle on
[debug]> set unwindonsignal on
[debug]> set print elements 0
[debug]> set debugevents on
[debug]> set disassembly-flavor att
[debug]> catch throw
...in a GDB script which you can edit through the debugger config. Then, you save the script to the application folder and source/use it as you do with "stl-views-1.0.3.gdb", too... What do you think?
oBFusCATed:
Some of them are controlled by options in the settings (catch throw, set disassembly-flavor att) and some of the others should not be user edited, because they will break debugging. (width, height, confirm)
"set debugevents on" is used only to detect the pid of the debuggee and when the pid is correctly detected "set debugevents off" should be executed.
I guess the pid reporting has changed, see the beginning of the GDB_driver::ParseOutput functions.
MortenMacFly:
--- Quote from: oBFusCATed on January 29, 2012, 07:59:15 pm ---"set debugevents on" is used only to detect the pid of the debuggee and when the pid is correctly detected "set debugevents off" should be executed.
--- End quote ---
I'm afraid it doesn't really work. The messages are less, but still a lot of these warnings make it through... I was wrong because I was pointing at a menu and then the messages are "turned off". That sucks. I guess I'll implement the filter as you suggested finally... Not really "nice" but it should work.
oBFusCATed:
So, you're saying that calling "set debugevents off" doesn't remove the messages?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version