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