From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9856 invoked by alias); 23 Feb 2012 03:32:47 -0000 Received: (qmail 9843 invoked by uid 22791); 23 Feb 2012 03:32:46 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 23 Feb 2012 03:32:32 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1S0PPz-0002Zb-37 from Yao_Qi@mentor.com ; Wed, 22 Feb 2012 19:32:31 -0800 Received: from SVR-ORW-FEM-05.mgc.mentorg.com ([147.34.97.43]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Feb 2012 19:32:29 -0800 Received: from [127.0.0.1] (147.34.91.1) by svr-orw-fem-05.mgc.mentorg.com (147.34.97.43) with Microsoft SMTP Server id 14.1.289.1; Wed, 22 Feb 2012 19:32:29 -0800 Message-ID: <4F45B324.2080609@codesourcery.com> Date: Thu, 23 Feb 2012 04:07:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0) Gecko/20120130 Thunderbird/10.0 MIME-Version: 1.0 To: Pedro Alves CC: Subject: Re: [PATCH] [RFC, docs RFA] gdbserver and gdb.threads/attach-into-signal.exp. References: <20120222171937.29946.56976.stgit@hit-nxdomain.opendns.com> In-Reply-To: <20120222171937.29946.56976.stgit@hit-nxdomain.opendns.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-02/txt/msg00493.txt.bz2 On 02/23/2012 01:19 AM, Pedro Alves wrote: > The issue is that when GDBserver detaches the inferior, it forgets the > SIGALRM signal it had found when it attached, so the inferior doesn't > get the signal (it is suppressed) and reaches the abort. The fix is > to make sure we forward the pending signals to the inferior on detach, > like gdb/linux-nat.c does. gdb/linux-nat.c does not pass down to the > inferior signals that are in the "handle SIG nopass" state, however. > GDBserver has no idea currently about the pass/nopass state of > signals, so in order for GDBserver to do the same GDB, we need to make > GDB tell GDBserver about the pass/nopass state of all signals. This > is recorded in GDB in the infrun.c:signal_program array. The patch > adds a new RSP packet QProgramSignals (similar to QPassSignals, though > with different semantics) to do exactly that. > Can we install target_ops hook to_program_signals in linux-nat, and move existings code in it? As you said, this problem doesn't exit on linux-nat, and a new target_ops hook to_program_signals is created, so it is natural to move existing linux-nat code to linux_nat_program_signals (it is to be created). > diff --git a/gdb/gdbserver/linux-low.c b/gdb/gdbserver/linux-low.c > index ab34d84..5353cff 100644 > --- a/gdb/gdbserver/linux-low.c > +++ b/gdb/gdbserver/linux-low.c > @@ -928,36 +928,125 @@ linux_kill (int pid) > return 0; > } > > +/* Get pending signal of LP, for detaching purposes. */ ^^ "THREAD" Can we remove the 2nd half of this setense "for detaching purpose". IIUC, this routine is quite general, so it might be used for other purpose in the future. > + > +static int > +get_pending_signal (struct thread_info *thread) > + > static int > linux_detach_one_lwp (struct inferior_list_entry *entry, void *args) > { > struct thread_info *thread = (struct thread_info *) entry; > struct lwp_info *lwp = get_thread_lwp (thread); > int pid = * (int *) args; > + int sig; > > if (ptid_get_pid (entry->id) != pid) > return 0; > > - /* If this process is stopped but is expecting a SIGSTOP, then make > - sure we take care of that now. This isn't absolutely guaranteed > - to collect the SIGSTOP, but is fairly likely to. */ > + /* If there is a pending SIGSTOP, get rid of it. */ > if (lwp->stop_expected) > { > - int wstat; > - /* Clear stop_expected, so that the SIGSTOP will be reported. */ > + if (debug_threads) > + fprintf (stderr, > + "Sending SIGCONT to %s\n", > + target_pid_to_str (ptid_of (lwp))); > + > + kill_lwp (lwpid_of (lwp), SIGCONT); > lwp->stop_expected = 0; > - linux_resume_one_lwp (lwp, 0, 0, NULL); > - linux_wait_for_event (lwp->head.id, &wstat, __WALL); > } > As described in changelog entry, (linux_detach_one_lwp): Get rid of a pending SIGSTOP with SIGCONT. Pass on pending signals to PTRACE_DETACH. Pending SIGSTOP is replaced with (pending?) SIGCONT. In original code, resume lwp -> wait -> PTRACE_DETACH (0). With this patch, it changed to PTRACE_DETACH (SIGCONT) directly, IIUC. I am wondering it may the status of program after detach, especiall when attach to a `T (stopped)' process at the beginning of debug session. I am unable to find a test case to proof, so I may be wrong. Just rise this question here. > /* Flush any pending changes to the process's registers. */ > regcache_invalidate_one ((struct inferior_list_entry *) > get_lwp_thread (lwp)); > > + /* Pass on any pending signal for this thread. */ > + sig = get_pending_signal (thread); > + > /* Finally, let it resume. */ > if (the_low_target.prepare_to_resume != NULL) > the_low_target.prepare_to_resume (lwp); > - ptrace (PTRACE_DETACH, lwpid_of (lwp), 0, 0); > + if (ptrace (PTRACE_DETACH, lwpid_of (lwp), 0, sig) < 0) > + error (_("Can't detach %s: %s"), > + target_pid_to_str (ptid_of (lwp)), > + strerror (errno)); > > delete_lwp (lwp); > return 0; -- Yao (齐尧)