This is the mail archive of the 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] [remote/gdbserver] Don't lose signals when reconnecting.

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 (éå)

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