Re: [RFC] canonical linespec and multiple breakpoints ...

[Matt Rice <ratmice@gmail.com>]

On Thu, May 26, 2011 at 2:05 PM, Tom Tromey <tromey@redhat.com> wrote:

> It is worth thinking about "time invariance".  E.g., suppose we adopt
> Jerome's "menu" plan.  In this case, an ambiguous linespec can present
> the user with a menu (depending on a setting).  But what happens if a
> linespec is not ambiguous, but then becomes ambiguous due to changes in
> the inferior?
>
> Time invariance and canonicalization also affects the multi-inferior
> case.  The current plan is to handle multi-inferior breakpoints using
> I/T sets; but it seems to me that these may match names in different
> ways across inferiors.  A simple example is just `break [*] main' --
> this either makes a single breakpoint (with all the attendant true
> multi-location problems), or binds eagerly (contra the `[*]' spec), or
> introduces a tiered breakpoint (but with a more complex example perhaps
> one requires 4 tiers?  It is unclear to me).

I guess it is worth noting that I had previously thought about the
Time invariance problem in isolation of the grouping problem.

At that time what I had imagined was a 'perpetually pending
breakpoint', or a 'pending rolling snowball breakpoint', basically a
pending breakpoint which is not removed when it is resolved, it
inserts the resolved breakpoint, but does not remove the pending one.

thinking about the grouping mechanism also in isolation leads one to
consider the idea of 'breakpoint groups',
where the 'perpetually pending breakpoint', contains a group ID, and
when it resolves, the newly inserted breakpoint gets inserted into the
same group as its pending one.

If a breakpoint group could contain breakpoint groups, as well as
breakpoints, we have a tiering mechanism.

Additionally i could see some benefit in being able to enable/disable
whole groups of breakpoints at a time.