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

[Pedro Alves <pedro at codesourcery dot com>]

On Tuesday 29 November 2011 22:02:11, Tom Tromey wrote:
> >>>>> "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

The breakpoint triggers if the thread that hits it is both
in [1.*], and is thread 3.

> How about something contradictory like
> 
>     [.2] break function thread 3

Breakpoint never triggers.  Given that the trigger set may well
be a dynamic set, it seems futile to try to detect such cases.  Just
don't do it.

> 
> 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.

I've defined it such that the thread that triggered the breakpoint
always stops, even if it is not in the stop set.  That meant that
and empty stop set is the same behavior as a breakpoint hit in
non-stop mode.  The alternative, and because we can't know upfront
which thread will hit the breakpoint, is to have a special set
for the thread that triggered (or more generaly, the current thread),
e.g.:

  [all] break -stop [@] LINESPEC

OTOH, `break -stop []' resuming the thread that hit the
breakpoint make the breakpoint look like a tracepoint.  Hmm.

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

E.g., when the event handling thread triggers this breakpoint (an
incoming event), stop everything in the DSP core.  Or all in the
inferior that sent the event.

> 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.  

Yeah, we've talked about that in the context of the objfile
sharing discussion, even IIRC.

> 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.

Well, the reaction is "yes".  :-)

> 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".

Thread-specific breakpoints on the target would necessarily get the
GDB thread number translated to the target thread number.  The target
never sees GDB thread numbers in any circunstance.  Thread-specific
breakpoints are already specified with the GDB generic thread number
(break foo thread N).  sets could be translated similarly.  Even if
the translation isn't 1-1, it's sufficient that the stop set as
sent to the target is larger and includes the whole of the set
specified by the user.  E.g., say we only support passing down one
thread id associated with a breakpoint.  If the set is unambiguously
for that thread, great, pass that thread id down to the target along
with the breakpoint.  If the breakpoint is set with a trigger set
that includes e.g., two threads, threads 1 and 2 of inferior 1,
select the next best target set that includes both of those threads.
That'd be, planting the breakpoint on the process of inferior 1 only,
but not in any other process, and have gdb transparently re-resume all
other threads if they trip on the breakpoint, just like thread-specific
breakpoints are handled today.

-- 
Pedro Alves