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

[Yao Qi <yao at codesourcery 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.

--
Yao (éå)