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: Pedro Alves <palves at redhat dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 25 Jul 2014 11:32:29 +0100
- 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> <838unhkciw dot fsf at gnu dot org>
On 07/25/2014 10:34 AM, Eli Zaretskii wrote:
>> Date: Thu, 24 Jul 2014 16:40:42 +0100
>> From: Pedro Alves <palves@redhat.com>
>>> +@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.
That looks great, thanks a lot! Would you mind if I drop the "by default",
though? When I read that I get the impression that there might be a knob
to configure this behavior, while there's none (and nor should there be one).
Like:
@emph{Note:} When resuming a multi-threaded program, @var{signal} is
- by default delivered to the currently selected thread, not the thread
+ 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
Thanks,
Pedro Alves