Splitting debugger in two - specific debugger and common GUI

[oBFusCATed]

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

[ollydbg]

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.

[oBFusCATed]

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.

[MortenMacFly]

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

[oBFusCATed]

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

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();
}

[MortenMacFly]

Morten how could I (in the GDB/mi plugin) derive from classes in GDB plugin?

Erm... just like

Code

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?

[oBFusCATed]

Erm... just like

Code

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.

[MortenMacFly]

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.

[oBFusCATed]

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?

[MortenMacFly]

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.

[mariocup]

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 .

[oBFusCATed]

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

[MortenMacFly]

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.

[oBFusCATed]

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

[oBFusCATed]

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?