This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v2] Always pass signals to the right thread.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]