News:

The new Release 25.03 is out! You can download binaries for Windows and many major Linux distros here .

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 August 01, 2009, 10:36:13 AM
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: [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 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.
(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 August 02, 2009, 10:35:09 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).

Quote from: oBFusCATed on August 02, 2009, 10:35:09 AM
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: [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'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!]

dmoore

when you get this sufficiently ready, I'll try to make some time to offer myself as guinea pig and write a python debugger.
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]

MortenMacFly

Quote from: oBFusCATed on August 13, 2009, 01:45:32 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: [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]

mariocup

Hi oBFrusCATed,

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


ollydbg

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.

oBFusCATed

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!]

ollydbg

My first question is:

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


@@ -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)


@@ -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.

ollydbg

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.next.codeblocks.org/index.php/topic,10708.msg73482.html#msg73482
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

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!]

oBFusCATed

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!]

ollydbg

Maybe, it is this function:


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.
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.

Jenna

Quote from: oBFusCATed 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).

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.