[PATCH] [remote/gdbserver] Don't lose signals when reconnecting.

[Yao Qi]

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.

-- 
Yao (齐尧)