Breakpoints
Andreas Pakulat
apaku at gmx.de
Sun Apr 5 19:12:45 UTC 2009
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...
Andreas
--
You would if you could but you can't so you won't.
More information about the KDevelop-devel
mailing list