This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC/WIP PATCH 09/14] I/T set support for breakpoints - trigger set, and stop set
>>>>> "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