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

Offline cbexaminr

  • Multiple posting newcomer
  • *
  • Posts: 104
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #405 on: February 08, 2011, 02:13:25 pm »
dbgextprocess.2(b).patch (b after recent trunk to debugger branch merges)

1)Change various text macro uses, and empty string "" to wxEmptyString
2)Verify that GUI is not gdb specific, but is used for both gdb and cdb (and try Debug external
process with cdb - see item 4)
3)Add cleanup of some overlooked vars on end of Debug external process
4)Fix bug introduced in recent cdb changes affecting Attach to process (new code in GetCommonCommandLine() referencing NULL m_Target) that also affected Debug external process

Awaiting advice on what to do differently than IsExternalProcess()...

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #406 on: February 08, 2011, 03:19:06 pm »
2)Verify that GUI is not gdb specific, but is used for both gdb and cdb (and try Debug external
process with cdb - see item 4)
Here I'm not talking about CDB, but the new python debugger or another kind of debugger, that can be used only in remote debugging mode (the lua debugger will be just like that if someday I start implementing it). My idea is to move the calling code inside the debugger, so you have the option to implement it or not.
This way the interface is a bit smaller... Also the GUI has too many thing in it.

Awaiting advice on what to do differently than IsExternalProcess()...
This one requires major refactoring. If it doesn't bother you, use your version for now. I'll give it a try myself next week, I think I'll have a bit of free time.
(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 cbexaminr

  • Multiple posting newcomer
  • *
  • Posts: 104
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #407 on: February 08, 2011, 08:11:55 pm »
... If it doesn't bother you, use your version for now...

The current state of the code on which I've already implemented the patch (and brought it forward several times in the past few months)
...does not bother me as much as...
having a patch with functionality 
A)that I find useful,
B)that is (or has been in the past) common functionality in at least 3 other IDEs (borland/cg/embt, visual studio, codelite) so is likely useful to others as well,
C)that does not seem to be philosophically out-of-line with other functionality in the patch target, and
D)that can currently be applied to the code as it is,
E)that does not seem to have any definite practical reason for not being applied

...with a delay in applying it until after some not-yet-begun architectural changes

a)requiring further work on someone's part (to bring it forward yet again) that could be avoided by its application, and
b)the lack of that functionality (no access to it) for others to whom it might be useful now or in the unknown interval when intended architectural changes and required (patch) rework are completed.
c)requires further work on my part to maintain and stay current with the debugger branch for whatever benefit that might provide me (and those working on it for whom I might be able to provide feedback in areas I use)

But, if you do not wish to apply, and the admins agree with that choice, then you may want to at least fix the crash it also addresses in cdb_driver::GetCommonCommandLine() when Attach to process is used with no project opened (which appears to have been introduced with the last previous patches for cdb).

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #408 on: February 08, 2011, 08:30:05 pm »
...does not bother me as much as...
Please guys, calm down. I believe oBFusCATed is truly willing to accept changes / patches that address the functionalities you have in mind. It is the same for me but I guess all that's missing for now is some more time. I for myself would be willing to try but simply don't have enough time, but I can understand your frustration coming out of this situation.

the admins agree with that choice
I cannot agree atm nor I disagree. When I look at the patch I see a lot TBD's so it seems unfinished to me. We already have a lot TBD's in the debugger plugin so adding more doesn't seem wise from an "outside" point of you. You see: Usually patches we apply are "finished"... even in the development branch (have a look at the history). The goal is to get the branch stable so it can be integrated into trunk. So I hope you also understand our point of view which is no way is disrespecting your work, btw! Every help is absolutely welcome!

However, as a compromise how about applying it for a nightly to give a chance to other users to try. If the community benefits from it we can polish out the ToDo's. But this should clearly be done in a continuous work.
« Last Edit: February 08, 2011, 08:34:26 pm by MortenMacFly »
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 dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #409 on: February 08, 2011, 11:13:36 pm »
Another options is
Code
MyPlugins::OnAttach(...)
{
    cbDebugger::OnAttach(...);
    ....
}

I actually slightly prefer this because most plugin devs are familiar with OnAttach and OnRelease, and calling a base class method is a familiar idiom (esp. in the wxWidgets world). I don't think OnAttachReal, DoAttach and friends are all that helpful to newbies, because they are basically synonyms of OnAttach that don't convey the nuanced meaning. Anyway, this is a style thing so I'm not going to push too hard (because I'm notorious for bad style).

I have plenty questions about the Debugging API. As a general comment, the cbDebuggerPlugin class definition could definitely use some more documentation, as I'm not always sure what the framework is providing and what the plugin needs to do (lack of time on your part, I know). A couple of specific questions (there will be more):

1. which is responsible for setting and moving the code position marker in the editor: the plugin or the framework? Assuming the framework, which methods need to be implemented in the plugin (and what other calls need to be made or events signalled) to get this to happen?
2. I noticed the the GDB_MI plugin was using some sort of smart pointer to store the breakpoint class instances (with the breakpoint class itself defined in the SDK). I would have thought the framework would provide the container classes...
« Last Edit: February 09, 2011, 05:58:37 am by dmoore »

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #410 on: February 09, 2011, 02:46:56 am »
On this:

1. which is responsible for setting and moving the code position marker in the editor: the plugin or the framework? Assuming the framework, which methods need to be implemented in the plugin (and what other calls need to be made or events signalled) to get this to happen?

It appears that correctly implementing IsStopped/IsRunning and then calling SyncEditor from the plugin is enough.

Offline cbexaminr

  • Multiple posting newcomer
  • *
  • Posts: 104
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #411 on: February 09, 2011, 04:31:22 am »
Please guys, calm down. I believe oBFusCATed is truly willing to accept changes / patches that address the functionalities you have in mind. It is the same for me but I guess all that's missing for now is some more time. I for myself would be willing to try but simply don't have enough time, but I can understand your frustration coming out of this situation.
oBFus is probably quite calm, unless I upset him, I probably am the one most needing to calm down, but...

The actual depths of my frustration you have no idea of.  Its roots date back prior to my join date of this forum.

Quote
However, as a compromise how about applying it for a nightly to give a chance to other users to try. <snip> from it we can polish out the ToDo's. But this should clearly be done in a continuous work.
If you wish to apply certainly.

TBD: ToBeDone, ToBeDetermined,ToBeDeleted, ToBeDiscussed

Of the TBD's still present (at least two I should have removed), I don't believe any of them currently require  any action, they are more ToBeDiscussed, if anyone has anything to offer regarding them.

Quote
If the community benefits from it ...
There may be an external community that could benefit if I can meet GPL compliance requirements for mingw built  gdb mods I have.  If the scrolling, leveled/layered, tipwindow can be completed  and incorporated(by someone), I think that would be of great benefit to that potential community as well.

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #412 on: February 09, 2011, 05:54:40 am »
I made a little progress tonight on the Python Debugger. For anyone interested in following along, the code is here

Code
svn checkout svn://svn.berlios.de/cbilplugin/trunk/PythonDebugger 

It's still a mess and has quite a few bugs. But you can sort of step through a python program and add/remove breakpoints.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #413 on: February 09, 2011, 08:37:31 am »
It appears that correctly implementing IsStopped/IsRunning and then calling SyncEditor from the plugin is enough.
You need to implement GetCurrentPosition too, it is called when an editor is opened.

I have plenty questions about the Debugging API. As a general comment, the cbDebuggerPlugin class definition could definitely use some more documentation, as I'm not always sure what the framework is providing and what the plugin needs to do (lack of time on your part, I know). A couple of specific questions (there will be more):
The main classes you should look at are:
DebuggerManager, the data classes in DebuggerManager.h, the classes for the debug windows and the cbDebuggerPlugin

Quote
2. I noticed the the GDB_MI plugin was using some sort of smart pointer to store the breakpoint class instances (with the breakpoint class itself defined in the SDK). I would have thought the framework would provide the container classes...
Most of the time the plugin is the owner of the data and then the GUI classes query the debugger for this data, so they can display it in some way.
Probably this is not the best design, but I wanted to change as little as possible and also to minimize the copying of data.
(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 cbexaminr

  • Multiple posting newcomer
  • *
  • Posts: 104
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #414 on: February 09, 2011, 07:48:52 pm »
... that can be used only in remote debugging mode... My idea is to move the calling code inside the debugger, so you have the option to implement it or not.
Awaiting advice on what to do differently than IsExternalProcess()...
This one requires major refactoring...

oBFus,

As mentioned in a caveat of the original (Debug external program) patch submission inclusion requested further above, I desire to support remote debugging access within the Debug external process functionality.  As also mentioned there, it appears some (possibly significant) study of the remote debugging info handling will be necessary for me to achieve that additional functionality.

Is it likely that your changes relative to remote debugging, and any associated major refactoring are going to affect the current structure and/or use of remote debugging info, such that any work I complete toward that functionality against the current state of the source plus my current changes, will require major rework to bring forward after your changes are completed?

While I would like to move forward in implementing that functionality now, I also do not wish to have to do the work twice, so your feedback on this appreciated...

*** i.e. should I wait to proceed with exploring how to, and subsequently implementing remote debugging within the Debug external program functionality for which I've already requested inclusion, until after you've completed, or report deciding not to, your planned changes in this area?

(somewhat aisde -
Regarding your suggestion elsewhere of using dummy or makefile projects to support these functionalities, they are "clunky" in regard to my anticipated usage patterns, a)either by cluttering my environment with otherwise useless projects, or b) requiring additional keystrokes to regularly access/change (remote) debugging info in a project configuration that may be opened multiple times simultaneously (with multiple codeblock instances) to explore issues that could occur on multiple nodes each running one/more identical concurrent application instance(s) of that (currently non-)codeblocks project in a multi-node test environment. 

Perhaps also worth mentioning, supporting multiple debug instances of the same application/project, with both/either remote and local instances, would support this use case as well, but I'm guessing, without trying [since there seems to be possibility of only one remote debugging info instance per project] that this is not currently supported.)

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #415 on: February 09, 2011, 10:04:51 pm »
Wait if you don't want to the the work twice, but how much I can't tell you...

BTW: I don't use remote debugging, so I do modify it only when someone ask for something to be added or fixed.

(somewhat aisde -
Regarding your suggestion elsewhere of using dummy or makefile projects to support these functionalities, they are "clunky" in regard to my anticipated usage patterns, a)either by cluttering my environment with otherwise useless projects, or b) requiring additional keystrokes to regularly access/change (remote) debugging info in a project configuration that may be opened multiple times simultaneously (with multiple codeblock instances) to explore issues that could occur on multiple nodes each running one/more identical concurrent application instance(s) of that (currently non-)codeblocks project in a multi-node test environment. 
This could be done by adding a way to have multiple remote debugging settings and a way to easily switch between them.
So it seems that you're using C::B as debugger wrapper and it is not a wrapper, it is an IDE -> so projects are first class citizens here.
There is single file compilation, but it is for students learning to program and no debugging there, too.

Perhaps also worth mentioning, supporting multiple debug instances of the same application/project, with both/either remote and local instances, would support this use case as well, but I'm guessing, without trying [since there seems to be possibility of only one remote debugging info instance per project] that this is not currently supported.)
GDB doesn't support multiple instances at the moment, so no such support is planned. GDB is going to support it someday then we will done something about it.
Implementing in C::B will be too hard and too unreliable, probably, I've not tried it...

Stay tuned...  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!]

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #416 on: February 09, 2011, 10:15:54 pm »
Quote
2. I noticed the the GDB_MI plugin was using some sort of smart pointer to store the breakpoint class instances (with the breakpoint class itself defined in the SDK). I would have thought the framework would provide the container classes...
Most of the time the plugin is the owner of the data and then the GUI classes query the debugger for this data, so they can display it in some way.
Probably this is not the best design, but I wanted to change as little as possible and also to minimize the copying of data.

Seems like a simple container defined in DebuggerManager.h (or wherever cbBreakpoint is defined) could take care of this:

Code
class BreakpointList
{
    cbBreakpoint *operator[](...); //array style access
    int GetCount(); //returns number of breakpoints
    cbBreakpoint *Add(file, line);    //returns NULL if request invalid
    bool Remove(cbBreakpoint *);  //returns true if successful
    int Find(cbBreakpoint *); //find index of breakpoint
    void RemoveAll();
}

This way, implementation details like smartpointers can be hidden away from the user. Potentially useful features, such as sorting of breakpoints could also be implemented in this class. (Users with advanced needs can obviously still roll their own).
« Last Edit: February 09, 2011, 10:21:00 pm by dmoore »

Offline cbexaminr

  • Multiple posting newcomer
  • *
  • Posts: 104
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #417 on: February 09, 2011, 10:20:13 pm »
GDB doesn't support multiple instances at the moment, so no such support is planned. GDB is going to support it
GDB doesn't need to support multiple directly, since multiple instances of GDB can be invoked.  

That is already done (by me at least), when codeblocks is used to debug itself, with the debugged codeblocks debugging yet another project/program.

The issue, or situation, I was outlining, is more related to having a possible need to have the same project open in more than one instance of codeblocks, assuming a user were forced to use a project to support debugging their application, but they need to debug multiple, possibly coordinating/cooperating instances of the target application.

[edit]Alternatively, the project may be open in only one codeblocks, but with other codeblocks instances debugging via the Debug external program functionality.
« Last Edit: February 09, 2011, 10:22:08 pm by cbexaminr »

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #418 on: February 09, 2011, 11:49:32 pm »
dmoore: probably it could be done this way, write it down in you nodes file and go on, later we can modify it, if you still think it is good thing. By the way smart pointer usage is a bit broken,
    because AddBreakpoint should return the smart pointer, not the pointee...I've added a TODO to look at it.

cbexaminr: The problem is with the synchronisation of the two+ instances and I think GDB could do it better, because they are closer to the OS.
    The debugger in VS 2005+ does this pretty well...
    Also it will make C::B's code way harder to read and write.

[edit]Alternatively, the project may be open in only one codeblocks, but with other codeblocks instances debugging via the Debug external program functionality.
You can open the project in many instances of C::B and use attach to process, the remote case won't work probably.
(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 #419 on: February 10, 2011, 07:34:13 pm »
dmoore: probably it could be done this way, write it down in you nodes file and go on, later we can modify it, if you still think it is good thing. By the way smart pointer usage is a bit broken,
    because AddBreakpoint should return the smart pointer, not the pointee...I've added a TODO to look at it.

I thought that there might have been an issue with shared_pointer usage but wasn't familiar enough to be sure. I wonder whether you really need them at all. Is there really that much of a cost to copy the breakpoint data?

If sharepointers are your preferred solution then I guess you should be doing something like:

Code
struct cbBreakpointInternal
{
        enum Type
        {
            Code,
            Data
        };
        wxString m_filename;
        wxString m_condition;
        int m_line;
        int m_ignoreCount;
        Type m_type;
        bool m_enabled;
        bool m_useIgnoreCount;
        bool m_useCondition;
        wxString m_dataExpression;
        bool m_breakOnRead;
        bool m_breakOnWrite;
};

class cbBreakpoint
{
    public:
        cbBreakpoint();
        cbBreakpoint(const wxString &filename, int line);
        cbBreakpoint(const wxString &dataExpression, bool breakOnRead, bool breakOnWrite);

        void SetLine(int line);
        void SetCondition(wxString const &condition);
        void SetIgnoreCount(int count);
        void SetEnabled(bool flag);
        void SetUseIgnoreCount(bool flag);
        void SetUseCondition(bool flag);

        const wxString & GetFilename() const;
        const wxString & GetCondition() const;
        int GetLine() const;
        int GetIgnoreCount() const;
        Type GetType() const;
        bool IsEnabled() const;
        bool UseIgnoreCount() const;
        bool UseCondition() const;

        const wxString& GetDataExpression() const;
        bool GetBreakOnRead() const;
        bool GetBreakOnWrite() const;

private:
        shared_pointer<cbBreakpointInternal> ptr;
}


class BreakpointList
{
    cbBreakpoint operator[](...); //array style access
    int GetCount(); //returns number of breakpoints
    cbBreakpoint Add(file, line);    //returns NULL if request invalid
    bool Remove(cbBreakpoint);  //returns true if successful
    int Find(cbBreakpoint); //find index of breakpoint
    void RemoveAll();
}


then the framework would work with copies of cbBreakpoint rather than (cbBreakpoint *)