Breakpoints

Vladimir Prus ghost at cs.msu.su
Wed Apr 15 09:06:38 UTC 2009


On Wednesday 15 April 2009 11:10:17 Andreas Pakulat wrote:

> > > > We technically can have a single list (as soon as we know
> > > > breakpoint->config association internally for the benefit of 'sync' state
> > > > display).
> > > 
> > > Why is there a breakpoint->config association?
> > 
> > Because config is the entity that sets breakpoints, and it should be
> > able to distinguish between:
> 
> Hmm, isn't it rather the debugger that sets it.
> 
> >   - Breakpoints that must be inserted, and are inserted
> >   - Breakpoints that must be inserted and are not, for any reason
> >   - Breakpoints that are irrelevant
> > 
> > In particular, display of  breakpoint in the breakpoint widget will
> > be decorated with different icons depending on which of the above
> > states is true.
> 
> But I don't see why you'd need to know the config for doing that.

Well, I hope you'll agree that we need some mechanism of understanding
what breakpoints are irrelevant for the current debug session. 

If we need such mechanism, then every breakpoint should have some properties,
and we should compare these properties with the properties of debug
session, to understand if the breakpoint is relevant, or not. Now, what are
those properties? It might be associated project. But then, a given "project"
might have a lot of different launch configs. Then, it make sense to
associate launch config both with breakpoint and debug session.

Can you suggest some other properties can be compared?

> > 1. Breakpoint table showing 100 breakpoints, only 5 of them are relevant
> > to the current lunch config
> 
> Ok, so we do need some kind of grouping.

Like, per launch config? I don't think that user will very appreciate
the need to explicitly create 'groups' in breakpoint widget.

> > 2. Launcher having to decide, using flaky heuristics, if a breakpoint
> > "belongs" to it and should be inserted, or, alternatively, trying
> > to insert all breakpoints.
> 
> Then how do you imagine that the user explains KDevelop which breakpoint
> should be used with which config? 

We'll have current launch config -- we already have it, and other IDEs have
it too. Newly added breakpoints are associated with the current launch config.


- Volodya




More information about the KDevelop-devel mailing list