Breakpoints

[Vladimir Prus]

On Wednesday 15 April 2009 22:37:11 Niko Sams wrote:
> On Wed, Apr 15, 2009 at 10:54 AM, Vladimir Prus <ghost at cs.msu.su> wrote:
> > On Wednesday 15 April 2009 10:42:54 Niko Sams wrote:
> >> > I don't understand the point about single breakpoint class -- it
> >> > seems independent from per-config/global discussion.
> >> because of GDBDebugger::Breakpoint::maybeSend. If we don't know to which
> >> Plugin a breakpoint belongs - we can't use a plugin-specific breakpoint class.
> >
> > Well, I imagine that no matter what we do, we might want to have specialized
> > breakpoints that are tightly coupled with specific debugger. Say, one debugger
> > might have 'break when function seem to messup callee-saved registers' (*).

> How should the user create such a breakpoint - UI-wise?

We'd need a mechanism for a plugin to contribute new action to a "new breakpoint"
command in the breakpoint widget.

> > - no KDevelop::Breakpoint::maybeSend
> > What code will be sending breakpoints in that case?
> a new class in the gdb plugin; GdbBreakpointController (as mentioned below)
> 
> >> - no KDevelop::Breakpoint::dirty_, KDevelop::Breakpoint::errors_
> > Just to clarify -- how the corresponding state will be displayed in the
> > breakpoint table otherwise?

> you mean the dirty-state? KDevelop::BreakpointController has to ask
> the _current_
> DebugSession about this state.

Ok, then you basically suggest to move the responsibility out of
breakpoint class. I did not think it through, but it sounds to me
basically an engineering decision -- if moving it makes some things
easier for you, why not?

> >> - a GDBDebugger::GdbBrekpointController (inherits QObject) per DebugSession
> >> - GdbBreakpointController adds the GDBCommands for sending the breakpoints
> >
> > So, in essence, you suggest that sending of breakpoint to debugger be handled
> > by a class different from breakpoint itself? This seems to be right approach
> > for breakpoints of generic kinds (line:number, say), and is probably ok
> > for custom breakpoint classes (where debugger-specific controller may just
> > dynamic_cast to some types and act accordingly).
> yes - that was my approach. I'm not sure if it's working
> 
> Imo we have two options:
> - every plugin has it's own Breakpoint class(es)
>    o when adding a breakpoint we must know the plugin where we create
> that breakpoint (this is actually my main problem)

Ah. I surely agree that file:line breakpoint class must not be different
in every plugin, and we should have a common class for that purpose --
and then it follows that converting such breakpoint to commands of specific
debugger should be handled in a different class -- like GDBBreakpointController
you have suggested. And yes, maybeSend definitely has to move.
Whether dirty_ has to move probably depends on whether we support two debug 
sessions in 4.0.

> - we have a common breakpoint class that works across all debuggers
>    o there could still be per-plugin special-breakpoint classes (that
> works for it's own plugin only)

This make sense to me.

- Volodya