Re: [RFC/WIP PATCH 09/14] I/T set support for breakpoints - trigger set, and stop set

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:

Tom> First, I've been thinking we should probably make breakpoint re-setting
Tom> more fine-grained.  The idea would be to classify the events that
Tom> current cause a re-set, giving them separate APIs in breakpoint.c, so
Tom> that we can make re-setting more efficient.  E.g., a new inferior should
Tom> not cause a breakpoint to reset if the breakpoint cannot possibly match
Tom> that inferior.  I'm just trolling for your reaction to this.

Also, I remembered that I think this has a small implication for the
itset code.  Some event may make it impossible for a breakpoint to ever
trigger again; for example it could be inferior-specific and the
inferior could exit.  It seems like it would be nice to either delete
the breakpoint in this case, or at least warn the user.  To do this, an
itset would need a method for "can this ever possibly match again", with
static sets being able to answer "no".

Tom