Author Topic: Splitting debugger in two - specific debugger and common GUI  (Read 429053 times)

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #15 on: August 01, 2009, 05:18:54 pm »
Where do I put a new header that should not be visible to the users in the sdk, only by the implementation?
Huh? What exactly do you mean? Notice that if the SDK needs this header file it had to be available.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #16 on: August 02, 2009, 10:35:09 am »
I have:
a.h,b.h,a.cpp,b.cpp

in a.cpp I include b.h. b.h is included in no other header, so it should not be visible to the users of the sdk.

Where do I put b.h? At the moment I've put it in src\include.

Another thing:

I want to add the method:

void cbDebuggerPlugin::GetBreakpoints(some_container_type &container);

What should be the some_container_type?
WX_DEFINE_ARRAY(cbBreakPoint*, BreakpointsList); ?
std::vector<cbBreakPoint> ?
or class cbBreakPointList, that I have to define, manually?

The elements in the container should be owned by the container.
« Last Edit: August 02, 2009, 06:05:01 pm by 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!]

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #17 on: August 03, 2009, 07:28:11 am »
in a.cpp I include b.h. b.h is included in no other header, so it should not be visible to the users of the sdk.
Just leave it where it is. The SDK docu will take care of not including this file in the documentation. Alternatively (if it's a small helper class) you can also embed it on top of the actual class (so in a.h) and comment it accordingly. There are several SDK classes that do similar (with the embedded classes *not* to be used directly).

WX_DEFINE_ARRAY(cbBreakPoint*, BreakpointsList); ?
std::vector<cbBreakPoint> ?
I'd personally prefer the first, but if that would be the only "wx code" and you'd strive for portability sure std::vector is the thing to do.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #18 on: August 13, 2009, 01:45:32 am »
I've some progress....  :lol: 8)

0. I've added a DebuggerManager, to hold all debugger related stuff
1. I've extracted the Debug menu (should move the resource file thought). The code is moved in the DebuggerMenu class.
1.1. Some of the menu items work (start, stop, step, next, continue)
1.2. I've added submenu Debug->Active Debugger. I've added API calls to register/unregister debuggers. The menu items are radio items, and switching the active debugger works.
2. I've extracted the breakpoints dialog and edit breakpoints
3. I've move the code from DebuggerGDB::SyncEditor to DebuggerManager::SyncEditor

Here is the patch that shows the changes: http://smrt.is-a-geek.org/codeblocks/dbg_refactor/dbg_refactor0001.patch
Parallel to the changes I make to CB, I modify my gdb_mi debugger plugin, so I can test if the changes are working.
The plugin can be found here: svn://smrt.is-a-geek.org/cb_gdb_mi .
The things that work: stepping and setting breakpoints at the beginning (before you have started the debugger).

Next on my TODO:
1. extracting the dbg toolbar
2. rewriting the watches window from scratch,  using PropGrid control - if you know about a control that is more suitable for it, please tell me (I'm a beginner in wx programming)

Any feedback is welcome.  :lol:
(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!]

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #19 on: August 13, 2009, 01:56:17 am »
when you get this sufficiently ready, I'll try to make some time to offer myself as guinea pig and write a python debugger.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #20 on: August 13, 2009, 06:27:28 am »
if you know about a control that is more suitable for it, please tell me (I'm a beginner in wx programming)
Great work so far. I'll try to apply the patch and see.
Concerning propgrid: If you want to use it please use the recent version of the wx (or wxCode) repo. Not the one bundled with wxSmith as this is very outdated. We have to update two plugins otherwise... ;-)
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

mariocup

  • Guest
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #21 on: August 13, 2009, 08:02:21 am »
Hi oBFrusCATed,

that sounds promising and I will take a look as soon as I have some free time.

« Last Edit: August 13, 2009, 09:35:18 am by mariocup »

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #22 on: August 13, 2009, 08:32:43 am »
Firstly, Thanks for your hard work!!!
The patches is only for Linux-like system, because only "CodeBlocks-unix.cbp" was modified. But I only has Windows system at hand. So, I need time to tune.
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.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #23 on: August 13, 2009, 09:30:23 am »
You could edit the patch manually and replace Codeblocks-unix.cbp with Codeblocks.cbp, it might work.
Although the changes aren't too massive, 4 new files and some moved files.

If someone fixes the windows project, he/she can send me the patch...
(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!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #24 on: August 13, 2009, 12:44:27 pm »
My first question is:

It seems there are files to be added to "sdk"(mainly header files), such as:

Code
@@ -508,6 +522,9 @@
  <Unit filename="include/editarraystringdlg.h">
  <Option target="sdk" />
  </Unit>
+ <Unit filename="include/editbreakpointdlg.h">
+ <Option target="sdk" />
+ </Unit>
  <Unit filename="include/editkeywordsdlg.h">
  <Option target="sdk" />
  </Unit>

and some files were added to "debugger"( mainly cpp files)

Code
@@ -1467,12 +1484,6 @@
  <Unit filename="plugins/debuggergdb/backtracedlg.h">
  <Option target="Debugger" />
  </Unit>
- <Unit filename="plugins/debuggergdb/breakpointsdlg.cpp">
- <Option target="Debugger" />
- </Unit>
- <Unit filename="plugins/debuggergdb/breakpointsdlg.h">
- <Option target="Debugger" />
- </Unit>
  <Unit filename="plugins/debuggergdb/cdb_commands.h">
  <Option target="Debugger" />
  </Unit>

So, my question is: Why not let them all stay in target "Debugger"?
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.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #25 on: August 13, 2009, 12:45:57 pm »
By the way, I can't directly apply your patch with TortoiseSVN.
So, I need to do it manually. :(

Edit
The only thing I would like to implement in sdk is that if we are debugging, we should only show the tooltip from debugger plugin. Currently, both codecompletion and debugger tooltip will be shown. Though, the former one will always be canceled by the later one.

See the related topic here:

http://forums.codeblocks.org/index.php/topic,10708.msg73482.html#msg73482
« Last Edit: August 13, 2009, 01:05:04 pm by ollydbg »
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.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #26 on: August 13, 2009, 02:04:17 pm »
ollydbg: Please read the first post in the thread, there I've explained why I'm doing this.

p.s. sorry for you problems with applying it, I've made the patch with "git diff" and I haven't tried to apply it.
p.s.s. the debugger plugin has more serious problems (slowness, bad watch window, etc) than the one you mention, so they have higher priority  for me.
(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!]

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #27 on: August 15, 2009, 04:29:31 pm »
I have a problem:
When I disable the DebuggerGDB plugin in "Plugin -> Manage plugins..." the "Debug" menu is removed.
Do someone knows where is the code that does the removal?
I couldn't find it and C::B crashes if I have two loaded debuggers and I try to disable both of them (tries to remove the menu twice).
(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!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #28 on: August 15, 2009, 04:55:53 pm »
Maybe, it is this function:

Code
bool PluginManager::DetachPlugin(cbPlugin* plugin)
{
    if (!plugin)
        return false;
    if (!plugin->IsAttached())
        return true;

    Manager::Get()->RemoveAllEventSinksFor(plugin);
    plugin->Release(Manager::IsAppShuttingDown());
    return true;
}

Then plugin->Release will do the whole job.
« Last Edit: August 15, 2009, 05:10:44 pm by ollydbg »
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.

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #29 on: August 15, 2009, 05:28:58 pm »
I have a problem:
When I disable the DebuggerGDB plugin in "Plugin -> Manage plugins..." the "Debug" menu is removed.
Do someone knows where is the code that does the removal?
I couldn't find it and C::B crashes if I have two loaded debuggers and I try to disable both of them (tries to remove the menu twice).

I guess the error is another.
If a plugin is released the menubar gets recreated from scratch, no single menus get removed.
That means a menu can not be removed twice.
If you debug C::B from inside C::B you should be able to see the backtrace of the crash (if the call stack window is active) and put a breakpoint there to see the cause.