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

[Tom Tromey <tromey@redhat.com>]

>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:

Pedro> This adds support for setting a breakpoint that only triggers on a
Pedro> given set (a superset of the current thread specific breakpoints
Pedro> support).  In addition, it adds support for specifying the set of
Pedro> threads that are suspended when the breakpoint is triggered.

Pedro> Breakpoints need two sets.  The trigger set, which is a generalization
Pedro> of the "break foo thread N", meaning the set of inferiors/threads
Pedro> where the breakpoint should fire, and, a suspend/stop set, which is
Pedro> the set of inferiors/threads that should be suspended when the
Pedro> breakpoint fires.

What happens if the user types:

    [1.*] break function thread 3

How about something contradictory like

    [.2] break function thread 3

Pedro> The trigger set of breakpoints is set from the current set at the time
Pedro> the breakpoint is created.  The stop set is passed explicitly as
Pedro> optional switch.  E.g.,:

Pedro>  [TRIGGER-SET] break [-stop [STOP-SET]] LINESPEC

Pedro> This leaves LINESPEC last, so that we can keep supporting the current
Pedro> form, but avoid more hacks in linespecs like the special termination
Pedro> for "thread/task/if" in the lexers --- that wouldn't work for `['.

Looks good to me.  Overdue, even :-)

Pedro> and, the stop set is inferred from the "set non-stop" global option.
Pedro> If non-stop is on, only the thread that triggers the breakpoint should
Pedro> be suspended; if non-stop is off, then all threads will be suspended
Pedro> when the breakpoint fires.

It seems to me that the stop set has to be a superset of the trigger
set.  Otherwise you get into a funny situation where a thread hits a
breakpoint, causing only other threads to stop.

Or maybe this is intentional?  I can't picture a use for it myself,
though.

Anyway, if this is a requirement, I think it should be enforced.

Pedro> +static int
Pedro> +bpstat_check_trigger_set (const struct breakpoint *b, struct thread_info *thread)
Pedro> +{
Pedro> +  if (b->trigger_set == NULL)
Pedro> +    return 1;
Pedro> +
Pedro> +  if (itset_contains_thread (b->trigger_set, thread))
Pedro> +    return 1;
Pedro> +
Pedro> +  return 0;

Delightfully simple.  A couple notes though...

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

Second, a while back on gdb@ there was some talk of pushing
thread-specific breakpoints to the target.  This still seems like a good
idea to me.  I just wonder how this would interact with trigger sets,
which are fairly general and which can depend on information known only
to gdb, like the inferior numbering.  I suppose one answer is, "use the
'thread' syntax for that".

Tom