Review Request: Common Debugger infrastructure

[Vladimir Prus]

On Wednesday 25 March 2009 00:24:03 Niko Sams wrote:
> 
> > On 2009-03-24 13:44:16, vladimir.prus wrote:
> > > trunk/KDE/kdevplatform/debugger/interfaces/idebugsession.h, line 60
> > > <http://reviewboard.kde.org/r/379/diff/2/?file=3493#file3493line60>
> > >
> > >     Same comment re cursor position applies.
> 
> better it should directly work with a BreakpointsModel and add the breakpoint there.

Then, maybe this method should not exist at all, and UI will just call the 
necessary method in BreakpointsModel
 
 > > On 2009-03-24 13:44:16, vladimir.prus wrote:
> > > trunk/KDE/kdevplatform/debugger/interfaces/idebugsession.h, line 52
> > > <http://reviewboard.kde.org/r/379/diff/2/?file=3493#file3493line52>
> > >
> > >     This method need a comment (just like other methods here, btw). In particular, does it interrupts the application, when it's running, or it interrupts the debugger itself when it is performing long-running operation that is not necessary related to running the program
> 
> once we know what they do we have to do that :D
> I was just moving all actions from gdb to this class.

Maybe, we should only move the methods that we know clear semantics for?

> > On 2009-03-24 13:44:16, vladimir.prus wrote:
> > > trunk/KDE/kdevplatform/debugger/interfaces/idebugsession.h, line 37
> > > <http://reviewboard.kde.org/r/379/diff/2/?file=3493#file3493line37>
> > >
> > >     This set of state is not sufficient for GDB purposes. There, we need to explicitly distinguish between 'GDB started' and 'GDB started and application started' states. Also, 'ActiveState' and 'PausedState' imply that the program is either running or stopped. With GDB non-stop mode some threads are running and others are stopped. The same debug approach is taken by Java. I'd recommend using some way to indicate 'debugger can respond', instead. If debugger can respond, then it means we can send it a command to ask about the state of individual threads.
> 
> Does the UI have to care about that? Basically this state is just to disable/enable various actions.

Which actions? Specifically, the "step" action should not be disabled when application
is running, because otherwise if user clicks "step" 10 times quickly, some of the
clicks will be eaten.

As for 'debugger accepts commannds' -- I think the *DB console would appreciate this
flag, as opposed to accepting user command and doing nothing.

- Volodya