News:

Accounts with zero posts and zero activity during the last months will be deleted periodically to fight SPAM!

Main Menu

Splitting debugger in two - specific debugger and common GUI

Started by oBFusCATed, July 26, 2009, 01:27:44 PM

Previous topic - Next topic

MortenMacFly

Quote from: oBFusCATed on May 28, 2010, 01:19:07 AM
http://smrt.is-a-geek.org/codeblocks/dbg_refactor0014.2.patch
Woot - you've been working hard obviously... Happy to hear that!

Quote from: oBFusCATed on May 28, 2010, 01:19:07 AM
1.2. I've made an unittest project for the parser (it uses unittest++) if anyone is interested I can provide it
If you want to have it added to SVN, like we did with the ParserTest project on the cc branch I can do it. I think it's just convenient to have it in one place. (We actually should have test projects for the core and all other plugins, too... ;-)).
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: [url="https://www.codeblocks.org/docs/main_codeblocks_en.html"]https://www.codeblocks.org/docs/main_codeblocks_en.html[/url]
C::B FAQ: [url="https://wiki.codeblocks.org/index.php?title=FAQ"]https://wiki.codeblocks.org/index.php?title=FAQ[/url]

oBFusCATed

Quote from: MortenMacFly on May 28, 2010, 06:57:33 AM
If you want to have it added to SVN, like we did with the ParserTest project on the cc branch I can do it. I think it's just convenient to have it in one place. (We actually should have test projects for the core and all other plugins, too... ;-)).
Maybe you the devs should choose a testing framework for C::B.
Then I can redo the tests if the framework is other than unittest++.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

MortenMacFly

Quote from: oBFusCATed on May 28, 2010, 10:11:03 AM
Maybe you the devs should choose a testing framework for C::B.
I guess most of us use unittest++, so this would most likely be the candidate.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: [url="https://www.codeblocks.org/docs/main_codeblocks_en.html"]https://www.codeblocks.org/docs/main_codeblocks_en.html[/url]
C::B FAQ: [url="https://wiki.codeblocks.org/index.php?title=FAQ"]https://wiki.codeblocks.org/index.php?title=FAQ[/url]

oBFusCATed

OK, two new patches:

http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0015.0.patch
1. Catching exceptions should work now.
2. Added command to disable the feature of gdb to shorten the lines in the output from commands.
    This should improve the reliability of the plugin.

http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0015.1.patch
CDB related patch:
1. Implemented switching to frame.
2. Implemented step into, step out (thanks blueshake).
3. Implemented watches. If anyone knows how to print the content of array in cdb, I can improve the watches. Now it prints the first element (most of the time).
4. Improve the handling of current position.

Tested with VC 9.1 aka VC 2008sp1, debugging tools "Previous Release version 6.11.1.404 - March 27, 2009"
Anyone interested in the CDB, please test and supply patches for features that don't work (there are plenty of them)
I'm running linux most of the time and on windows I use gcc + gdb, so I can't test CDB's integration in "production", much.

Morten, after this patch I suppose the branch could be merged in trunk...  :lol: 8)
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

ollydbg

Quote from: oBFusCATed on June 29, 2010, 01:08:34 AM
OK, two new patches:

http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0015.0.patch
1. Catching exceptions should work now.
2. Added command to disable the feature of gdb to shorten the lines in the output from commands.
    This should improve the reliability of the plugin.

http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0015.1.patch
CDB related patch:
1. Implemented switching to frame.
2. Implemented step into, step out (thanks blueshake).
3. Implemented watches. If anyone knows how to print the content of array in cdb, I can improve the watches. Now it prints the first element (most of the time).
4. Improve the handling of current position.

Tested with VC 9.1 aka VC 2008sp1, debugging tools "Previous Release version 6.11.1.404 - March 27, 2009"
Anyone interested in the CDB, please test and supply patches for features that don't work (there are plenty of them)
I'm running linux most of the time and on windows I use gcc + gdb, so I can't test CDB's integration in "production", much.

Morten, after this patch I suppose the branch could be merged in trunk...  :lol: 8)


You have done a wonderful achievement. :D
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

oBFusCATed

One more change I have in my working copy is this:


===================================================================
--- sdk/globals.cpp     (revision 6372)
+++ sdk/globals.cpp     (working copy)
@@ -210,6 +210,9 @@
{
     wxString ext = filename.AfterLast(_T('.')).Lower();

+    if (ext.find(wxT('/')) != wxString::npos)
+        return ftHeader;
+
     if (ext.IsSameAs(FileFilters::ASM_EXT) ||
         ext.IsSameAs(FileFilters::C_EXT) ||
         ext.IsSameAs(FileFilters::CC_EXT) ||
Index: sdk/cbplugin.cpp
===================================================================
--- sdk/cbplugin.cpp    (revision 6372)
+++ sdk/cbplugin.cpp    (working copy)
@@ -254,7 +254,7 @@
         }
     }
     FileType ft = FileTypeOf(filename);
-    if (ft != ftSource && ft != ftHeader && ft != ftResource)
+    if ((ft != ftSource && ft != ftHeader && ft != ftResource) || line < 0)
     {
         if(log_index != -1)
         {


I've added it in order to enabled switching to frames inside headers from the C++'s standard library (vector, string, exception, etc).
I know this is not the right solution, but I'm not sure it if can be done without hacks.
Any suggestions are welcome and desired!
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

MortenMacFly

Quote from: oBFusCATed on June 29, 2010, 01:08:34 AM
OK, two new patches:
Applied and merged with trunk. The latter is untested... just take it as a warning. I just came back and have other things to do before testing this myself...
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: [url="https://www.codeblocks.org/docs/main_codeblocks_en.html"]https://www.codeblocks.org/docs/main_codeblocks_en.html[/url]
C::B FAQ: [url="https://wiki.codeblocks.org/index.php?title=FAQ"]https://wiki.codeblocks.org/index.php?title=FAQ[/url]

oBFusCATed

Morten: Latter should be the CDB's patch, shouldn't it?
What about the header hack, do you know a better way to handle this?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

MortenMacFly

Quote from: oBFusCATed on July 12, 2010, 12:42:16 PM
Morten: Latter should be the CDB's patch, shouldn't it?
Yes.

Quote from: oBFusCATed on July 12, 2010, 12:42:16 PM
What about the header hack, do you know a better way to handle this?
I don't know a better way. A file without an extension could be ANYTHING. So it's really a hack and surely will introduce side-effects. The question is if these side-effects are critical and if the benefits are worth it.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: [url="https://www.codeblocks.org/docs/main_codeblocks_en.html"]https://www.codeblocks.org/docs/main_codeblocks_en.html[/url]
C::B FAQ: [url="https://wiki.codeblocks.org/index.php?title=FAQ"]https://wiki.codeblocks.org/index.php?title=FAQ[/url]

oBFusCATed

I could move this check to the cbDebuggerPlugin, so the damage could be limited a bit :)
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

oBFusCATed

The branch is broken :(


Index: src/plugins/debuggergdb/cdb_driver.cpp
===================================================================
--- src/plugins/debuggergdb/cdb_driver.cpp      (revision 6402)
+++ src/plugins/debuggergdb/cdb_driver.cpp      (working copy)
@@ -191,7 +191,7 @@
     QueueCommand(new CdbCmd_InfoRegisters(this));
}

-void CDB_driver::SwitchToFrame(size_t /*number*/)
+void CDB_driver::SwitchToFrame(size_t number)
{
     ResetCursor();
     QueueCommand(new CdbCmd_SwitchFrame(this, number));
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

dmoore

Quote from: oBFusCATed on May 06, 2010, 05:21:35 PM
I've just found a problem in the shutdown procedure of C::B


void MainFrame::OnApplicationClose(wxCloseEvent& event)
{
.......
   if (!Manager::IsBatchBuild())
   {
       m_pInfoPane->Destroy();
       m_pInfoPane = 0L;
   }

   Manager::Shutdown(); // Shutdown() is not Free(), Manager is automatically destroyed at exit



And the problem is: the log & info notebook is destroyed (all child logger controls too) before all plugins are destroyed/unloaded.
The result is that the logger system has pointers to destroyed objects => we get a crash every time such a pointer is used (for example in TextCtrlLogger::Append).

How should this problem be fixed?
1. Move the notebook's destruction below the Manager::Shutdown(); call
2. Add a method to the LogManager -> MarkAsDestroyed, which does  "control = NULL"
3. Something else

Slightly O/T, but has this issue been resolved in C::B trunk? I think this was a cause of crashes on exit with my FileManager plugin (which was using the logs to show some debugging info).
Python plugins: [url="https://github.com/spillz/codeblocks-python"]https://github.com/spillz/codeblocks-python[/url]
Code::Blocks Daily Builds -- Ubuntu PPA: [url="https://launchpad.net/~damien-moore/+archive/codeblocks"]https://launchpad.net/~damien-moore/+archive/codeblocks[/url]

oBFusCATed

(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

MortenMacFly

Quote from: dmoore on July 21, 2010, 05:10:30 PM
Slightly O/T, but has this issue been resolved in C::B trunk? I think this was a cause of crashes on exit with my FileManager plugin (which was using the logs to show some debugging info).
I wasn't aware of that (or missed it).

Quote from: dmoore on July 21, 2010, 05:10:30 PM
1. Move the notebook's destruction below the Manager::Shutdown(); call
I would simply prefer that solution. Did you try, if that works?
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: [url="https://www.codeblocks.org/docs/main_codeblocks_en.html"]https://www.codeblocks.org/docs/main_codeblocks_en.html[/url]
C::B FAQ: [url="https://wiki.codeblocks.org/index.php?title=FAQ"]https://wiki.codeblocks.org/index.php?title=FAQ[/url]

oBFusCATed

Quote from: MortenMacFly on July 22, 2010, 07:31:39 AM
I would simply prefer that solution. Did you try, if that works?
I'm not sure, but I think haven't.
I could try it.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]