This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH] [remote/gdbserver] Don't lose signals when reconnecting.
- From: Yao Qi <yao at codesourcery dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: <gdb-patches at sourceware dot org>
- Date: Wed, 6 Nov 2013 20:28:36 +0800
- Subject: Re: [PATCH] [remote/gdbserver] Don't lose signals when reconnecting.
- Authentication-results: sourceware.org; auth=none
- References: <1383591233-20940-1-git-send-email-palves at redhat dot com> <5279E470 dot 7060603 at codesourcery dot com> <527A3227 dot 2080308 at redhat dot com>
On 11/06/2013 08:12 PM, Pedro Alves wrote:
We'll still lose an asynchronous SIGTRAP. That is, e.g., if the
program was stopped due to a '$kill -SIGTRAP $pid' from the shell.
On Linux, we can tell whether a signal was sent by the kernel or
by the program by looking at siginfo->si_code (SI_USER, SI_KERNEL,
etc., see /usr/include/bits/siginfo.h).
Note that since most stubs out there, including GDBserver, are
always reporting GDB_SIGNAL_TRAP on initial connection (instead of
GDB_SIGNAL_0), GDB will have to keep silently swallowing
GDB_SIGNAL_TRAP. We'd also need a new target feature to get
around that. Given that "all-stop on top of non-stop" wouldn't
have that problem (as stubs report GDB_SIGNAL_0 for stopped threads,
not GDB_SIGNAL_TRAP), I'm not bothering with that.
That is clear to me now, thanks.
>>@@ -2544,13 +2635,15 @@ handle_status (char *own_buf)
>> /* GDB is connected, don't forward events to the target anymore. */
>> for_each_inferior (&all_processes, gdb_reattached_process);
>>+ discard_queued_stop_replies (-1);
>>+ for_each_inferior (&all_threads, clear_pending_status_callback);
>> /* In non-stop mode, we must send a stop reply for each stopped
>> thread. In all-stop mode, just send one for the first stopped
>> thread we find. */
>> if (non_stop)
>>- discard_queued_stop_replies (-1);
>I'd like to figure out the reason call discard_queued_stop_replies in
>all-stop mode. We want to handle the case that all-stop GDB connects to
>a non-stop GDBserver, and discard all previous stop replies,
Yes, that. Perhaps even better would be to discard them immediately
when the previous GDB disconnects. We don't queue stop replies if
GDB isn't connected (disconnected tracing) anyway.
Yes, I agree. I have no other comments on this patch.