From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26226 invoked by alias); 9 May 2008 20:18:14 -0000 Received: (qmail 26217 invoked by uid 22791); 9 May 2008 20:18:14 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 09 May 2008 20:17:57 +0000 Received: (qmail 12822 invoked from network); 9 May 2008 20:17:55 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 9 May 2008 20:17:55 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [RFC] 10/10 non-stop for linux native Date: Sat, 10 May 2008 02:54:00 -0000 User-Agent: KMail/1.9.9 Cc: Michael Snyder , Eli Zaretskii References: <200805061650.10912.pedro@codesourcery.com> <200805090253.21680.pedro@codesourcery.com> <1210361218.4615.516.camel@localhost.localdomain> In-Reply-To: <1210361218.4615.516.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805092117.56176.pedro@codesourcery.com> 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: 2008-05/txt/msg00328.txt.bz2 A Friday 09 May 2008 20:26:58, Michael Snyder wrote: > We are extending the envelope here. Ptrace was not designed > with non-stop or asynch debugging in mind. I'm not relying on some unspecified ptrace behaviour against running lwps that happens to be convenient. With ptrace, we can inspect and modify inferior processes while they are stopped, only. It they are running, we can't read registers or memory from them. I'm simply ensuring never to use ptrace against a running lwp, ever. The only two "issues" with ptrace here, but those only arose, because we assumed all lwps were always stopped. We were always talking to thread-db through the the main lwp of the thread group (proc-service.c/linux-thread-db.c:proc_handle.pid). In all-stop that is ok, as all lwps are stopped at that point. In non-stop, when some other lwp other then the main lwp gets an event (a breakpoint, say), since we don't stop all threads, proc-service would fail -- the main lwp could be running. But, we know the event lwp is stopped at that point, so we should have proc_services use the event pid -- because we can use ptrace on it. The other issue is that linux_nat_thread_alive assumed the passed in ptid is stopped when it is called, because that is always true in all-stop mode. Since that is not true in non-stop, I switched the linux implementation to check if the lwp is alive by "sending" signal 0 instead of relying on ptrace(PEEK_USER). -- Pedro Alves