Breakpoints

[Vladimir Prus]

On Sunday 05 April 2009 23:12:45 Andreas Pakulat wrote:
> On 04.04.09 17:21:20, Niko Sams wrote:
> > For the generic debugger stuff we need a common breakpoints widget -
> > else every debugger
> > plugin would provide it's own breakpoints dock. (Do we agree on that?
> > Or could there be debugger
> > differencies that makes that difficult?)
> > 
> > To have breakpoints across debuggers I see two options:
> > 1. every debugger has it's own Breakpoint-Model (BreakpointController)
> > and when the user adds a breakpoint
> >   in the editor it is somehow decided what debugger plugin can handle
> > this breakpoint and that one adds it to it's model.
> >   Then the Breakpoint-Widget needs either collect the Breakpoints from
> > all debuggers, or switch between
> >   debuggers.
> >   With this option the gdb Breakpoints can stay as they are.
> > 
> > 2. a single debugger independet Breakpoint-Model all debuggers access.
> > NewBreakpoint::sendMaybe as to
> >    be moved somewhere else then.
> >    This option makes it difficult to add debugger specific features
> > (for example not every debugger
> >    supports "Ignore __ next hits")
> 
> Well, we can always have some parts of the generic model be optional
> (for example the mentioned ignore X next hits). We already have other
> places where this is the case, for example the whole project management
> stuff. There are two interfaces, one is specific for buildtools and a
> project might have only the non-buildtool one. In the same way we can
> have an interface for "standard" breakpoints and a new one that
> subclasses the first that has extended capabilities like "ignore X next
> hits". 
> 
> In general I think a debugger-independant breakpoint model is better as
> it allows arbitrary plugins to hook into the debug process or maybe even
> create breakpoints themselves. Think about integration of a hexeditor.

I think the big question is not whether the C++ class implementing the breakpoint
model is the same for all debuggers, or not. The question is whether there's a single
breakpoint model instance in KDevelop session. Because it a breakpoint is given
a pile of breakpoints, some of which are for different projects, or different
launchers, it might very well be confused. In particular, current breakpoint
widget has a 'state' column, that can be either 'dirty' or 'synchronized'. This
is somewhat important for C++, since breakpoints in shared libraries are not resolved
until shared libraries are loaded, and it would be nice to see if that worked out.

If breakpoint model includes breakpoints from all project, breakpoint widget cannot
figure which breakpoints *should* be inserted, and cannot meaningfully show state.

Maybe, the right solution would be to explicitly introduce 'current launch config',
make breakpoints be associated with a config by default, and show only breakpoints
in the current config. We might need 'global' breakpoints -- but I'd suggest not
doing this until we see obvious need.

- Volodya