This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v2] Always pass signals to the right thread.
- From: Eli Zaretskii <eliz at gnu dot org>
- To: Pedro Alves <palves at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 25 Jul 2014 12:34:15 +0300
- Subject: Re: [PATCH v2] Always pass signals to the right thread.
- Authentication-results: sourceware.org; auth=none
- References: <1403183341-12581-1-git-send-email-palves at redhat dot com> <53A790DB dot 40908 at codesourcery dot com> <53A9648F dot 1030006 at redhat dot com> <53D128FA dot 6030901 at redhat dot com>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> Date: Thu, 24 Jul 2014 16:40:42 +0100
> From: Pedro Alves <palves@redhat.com>
> CC: Eli Zaretskii <eliz@gnu.org>
>
> Could you take a look at the documentation bits of this patch?
Below.
> > *** Changes since GDB 7.8
> >
> > +* On resume, GDB now always passes the signal the program had stopped
> > + for to the thread the signal was sent to, even if the user changed
> > + threads before resuming. Previously GDB would often (but not
> > + always) deliver the signal to the thread that happens to be current
> > + at resume time.
> > +
> > +* Conversely, the "signal" command now consistently delivers the
> > + requested signal to the current thread. GDB now asks for
> > + confirmation if the program had stopped for a signal and the user
> > + switched threads meanwhile.
OK for this part.
> > +@emph{Note:} When debugging multi-threaded programs, @var{signal} is
> > +delivered to the currently selected thread, not the thread that last
> > +reported a stop. If for example the program last stopped on account
> > +of a signal in thread 2 and you want to continue execution suppressing
> > +that signal, you must have thread 2 selected as current before issuing
> > +the @samp{signal 0} command. @value{GDBN} detects the scenario and
> > +asks for confirmation if you had switched threads meanwhile.
This description is IMO confusing, as it changes the described
situation at least twice. I suggest this text instead:
@emph{Note:} When resuming a multi-threaded program, @var{signal} is
by default delivered to the currently selected thread, not the thread
that last reported a stop. This includes the situation where a thread
was stopped due to a signal. So if you want to continue execution
suppressing the signal that stopped a thread, you should select that
same thread before issuing the @samp{signal 0} command. If you issue
the @samp{signal 0} command with another thread as the selected one,
@value{GDBN} detects that and asks for confirmation.
Otherwise, OK.
Thanks.