Breakpoints

[Vladimir Prus]

On Wednesday 15 April 2009 22:49:37 Andreas Pakulat wrote:
> On 15.04.09 20: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?
> 
> Hmm, why do we even care at this point? How about we take a step back and
> _first_ think about making the common use-cases working properly instead of
> optimizing for seldomly used features. We can always break BC later on if
> we find out that we need to to support such things.

Well, ideally, we consider future direction so that not to rewrite design
completely later. But yes, common features first.

And if we return to the topic of this thread -- breakpoint representation,
it seems to me that the most common scenario is that list of breakpoints
used when debugging C++ applications with GDB and list of breakpoints
used when debugging PHP application are disjoint. Should we probably
optimize for this case?

> And yes, this can also include dropping the idea of multiple debugged
> applications at the same time - at least for 4.0.

IMO, that's desirable. Whilst there are cases when one should debug
two communicating applications, this is relatively rare.

- Volodya