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

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12002
    • Travis build status
Hello,

I've played a bit with the GDB plugin trying to increase its speed, but I'm sure that is not possible much.
So I decided to make a new plugin using the GDB/mi interface.
I've done some testing made the thing execute commands and handle the output, but there is one major problem of C::B in that regard:
I've to reimplement all the GUI - watch, threads, call stack, register windows and menu.
I've reimplemented the menu, so I can play with it and now in my CB there are two menus one is Debug and the other Debug/MI.
And that is with only two debuggers, the mess will be massive if someone implements Lua (I would do it if we get the common interface), Python, etc debuggers.

My idea is to split the debugger plugin in two parts: a plugin that communicates with the actual debugger and a plugin/sdk that implements the GUI.
I would do the whole thing, I just need guidance, little help and a green light, so I know that this change is desired.

Best regards,
Teodor
(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: 5226
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #1 on: July 26, 2009, 01:36:37 pm »
Great!
But what does "GDB/mi interface" means?

By the way: I found that the current GDB may add some python add-on, I'm not sure you can use them.
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: 12002
    • Travis build status
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #2 on: July 26, 2009, 04:19:22 pm »
ollydbg: see here http://sources.redhat.com/gdb/current/onlinedocs/gdb_26.html#SEC270 about gdb/mi ...
I don't care about python at the moment or ever will, what I want is to make extending debugging in CB easier.
Python/Lua were just examples what could be done in the future.
(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: 9496
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #3 on: July 26, 2009, 08:45:07 pm »
My idea is to split the debugger plugin in two parts: a plugin that communicates with the actual debugger and a plugin/sdk that implements the GUI.
I understand why you want to do this, but isn't it possible (with the current code) to derive those UI parts from existing code and override the "incompatible" parts? If not I think it should be done careful, meaning taking other debuggers into account, too. That is if we do a general UI for GDB and GDB/MI the question is does it work with CDB and others, too? (Not saying it's not doable.)
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12002
    • Travis build status
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #4 on: July 26, 2009, 09:30:08 pm »
Morten how could I (in the GDB/mi plugin) derive from classes in GDB plugin? Or I have understood you incorrectly?

I don't think CDB is a concern because the current implementation works for both (only the drivers are different).
The hardest thing to abstract in the debugger part of CB is the watch window, the others would be straight forward.

For example the call stack window usage could look like this:
Code: [Select]

void MyDBG::OnUpdateCallStack()
{
    cbCallStackWindow *window = Manager::Get()->GetDebuggerUI(CB_DBG_UI_CALL_STACK);

    if(!window || !window->IsVisible())
        return;

    window->StartUpdating();

    foreach(frame in m_call_stack_frames)
    {
        window->AddFrame(cbCallStackFrame(frame.path, frame.addr, frame.symbol));
    }
    window->FinishUpdating();
}
(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: 9496
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #5 on: July 28, 2009, 08:34:50 am »
Morten how could I (in the GDB/mi plugin) derive from classes in GDB plugin?
Erm... just like
Code: [Select]
class Gdb
{
    public:
        void GdbFunction(){ // gdb code }
};

class NewGdb : public Gdb
{
    public:
        void GdbFunction(){ // new_gdb code }
        void NewGdbFunction(){}
};

void new_gdb_plugin()
{
    NewGdb new_gdb;
}
etc... But probably I have misunderstood?
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12002
    • Travis build status
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #6 on: July 28, 2009, 10:52:07 am »
Erm... just like
Code: [Select]
class Gdb
{
    public:
        void GdbFunction(){ // gdb code }
};

class NewGdb : public Gdb
{
    public:
        void GdbFunction(){ // new_gdb code }
        void NewGdbFunction(){}
};

void new_gdb_plugin()
{
    NewGdb new_gdb;
}
etc... But probably I have misunderstood?
First you have missed the virtual up there:)
The question was a bit rhetorical, though. I can derive from a class that is not exported (no public include, no __declspec(export/import)).
To be able to derive from such class, some changes should be made in the current debugger plugin. Also my new plugin would become dependent on the old one, but it should work with the old plugin, there should not be related in any way.

Decoupling the gui from the debugger plugin will make writing of both easier. Also the plugins would be easier to read, understand and extend.
(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: 9496
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #7 on: July 28, 2009, 12:11:01 pm »
First you have missed the virtual up there:)
Nar... but you got the idea.

Decoupling the gui from the debugger plugin will make writing of both easier. Also the plugins would be easier to read, understand and extend.
So - I have no doubts about that but again my question is: If we "polish" the current interfaces / classes so we can derive from them where needed may b less work. But it's really just a question - so it's probably not.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12002
    • Travis build status
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #8 on: July 28, 2009, 01:14:22 pm »
I suppose the simpler windows (call stack, threads, registers) could be modified, and not rewritten from scratch.
But the most complex and time consuming window, the watch window, could not.
In my opinion it should be rewritten using the PropGrid class/widget (or something similar). At the moment it is quite annoying and not user friendly.

So do I have a green light to start working on such a feature/refactoring? And would my work be accepted in C::B?
(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: 9496
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #9 on: July 28, 2009, 03:20:27 pm »
So do I have a green light to start working on such a feature/refactoring?
Sure - who can stop you anyways?! ;-)

And would my work be accepted in C::B?
If it's working and well written I am happy to keep track and apply if ready. Please just try to use the same style as in the debugger plugin.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline mariocup

  • Developer
  • Lives here!
  • *****
  • Posts: 587
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #10 on: July 28, 2009, 03:29:11 pm »
Hi oBFusCATed,

some time ago I collect some requirements that I see for a debugger, especially if you want to use it for embedded application (see Section Embedded at http://wiki.codeblocks.org/index.php?title=User_talk:Mariocup).
The most important features in my eyes are:
- Extension Points for options
- Mixed Mode
- Multiple Watch Windows

If you are refactoring it, perhaps there will be some new concepts to integrate some of the features :D.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12002
    • Travis build status
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #11 on: July 29, 2009, 12:04:29 am »
Sure - who can stop you anyways?! ;-)
That is true, but I don't want to maintain extremely modified copy of CB, so if the changes would be accepted in the main source, I'll do better work.

If it's working and well written I am happy to keep track and apply if ready. Please just try to use the same style as in the debugger plugin.
Coding style?

Another thing:
I need to keep the thing in a VCS, shuffling patches around would be nasty.
There are some options:
1. I could import the thing in a git repo and publish it, but I'm not sure how well does git works on windows. And I've never used git before.
2. You could make me new branch in the official repo, and give me write access to that branch, so you can follow the progress and stop me from doing stupid things early in the process.
3. Any other option you could think of, and I've missed.

p.s. I don't insist on option 2
p.s.s. mariocup: It is too early to think about such features, though some of the sound logical and not that hard to implement, so time will tell what will happen :)
(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: 9496
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #12 on: July 29, 2009, 08:05:57 am »
Coding style?
Yes - we have some instructions accordingly in the WiKi.

I need to keep the thing in a VCS, shuffling patches around would be nasty.
3. Any other option you could think of, and I've missed.
Granting access on out repo can only one: The Admin Yiannis.
But I suggest you create yourself an account on BerliOS (so that we share the same platform) and have your own repo there... just as a lot other plugins do it, too. It's very simple to setup.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12002
    • Travis build status
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #13 on: July 29, 2009, 04:38:58 pm »
I'm not sure that I like berlios, so if it will be external repo I'll go with GIT.
Because it has svn integration, so syncing my repo with trunk will be easier.
And it's time to learn 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!]

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12002
    • Travis build status
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #14 on: August 01, 2009, 10:36:13 am »
I've started working on it ... and I have a little problem:
Where do I put a new header that should not be visible to the users in the sdk, only by the implementation?
(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!]