From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25025 invoked by alias); 9 May 2008 19:27:18 -0000 Received: (qmail 25013 invoked by uid 22791); 9 May 2008 19:27:17 -0000 X-Spam-Check-By: sourceware.org Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 09 May 2008 19:27:00 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id 906153BD75; Fri, 9 May 2008 12:26:58 -0700 (PDT) Subject: Re: [RFC] 10/10 non-stop for linux native From: Michael Snyder To: Pedro Alves Cc: gdb-patches@sourceware.org, Eli Zaretskii In-Reply-To: <200805090253.21680.pedro@codesourcery.com> References: <200805061650.10912.pedro@codesourcery.com> <200805090253.21680.pedro@codesourcery.com> Content-Type: text/plain Date: Fri, 09 May 2008 22:10:00 -0000 Message-Id: <1210361218.4615.516.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-7.fc7) Content-Transfer-Encoding: 7bit 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/msg00325.txt.bz2 On Fri, 2008-05-09 at 02:53 +0100, Pedro Alves wrote: > A Thursday 08 May 2008 12:47:56, Eli Zaretskii wrote: > > > From: Pedro Alves > > > Date: Tue, 6 May 2008 16:50:10 +0100 > > > > > > This adds non-stop support for linux native. > > > > > > The changes are: > > > > > > - ptracing a running thread doesn't work. > > > > > > This implies that, we must ensure that the proc_services > > > usage in linux-thread-db.c talks to a pid of a stopped lwp. > > > > > > Checking if a thread is alive with ptrace doesn't work > > > for running threads. Worse, ptrace errors out claiming > > > the thread doesn't exits. > > > > > > - We must not stop all threads, obviously. > > > > > > - We must mark threads as running if we're resuming > > > them behind the core's back. > > > > > > - Implement target_stop_ptid to interrupt only one thread > > > > I know nothing about the Linux kernel or ptrace implementation, but > > the above description sounds as if we are coding around ptrace/kernel > > bugs. Are we? > > It's just how ptrace works. There are some things that could be > changed, but we have added workarounds for real bugs in that past, > and these are not bugs, more like the "personality" of the mostly > unspecified behaviour of ptrace. > > ptrace only works against a stopped lwp. > > That being said, the most surprising ptrace issue is returning > ESRCH on a running threads, which makes the target_thread_alive > return wrong results for running threads. We are extending the envelope here. Ptrace was not designed with non-stop or asynch debugging in mind.