From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31314 invoked by alias); 9 May 2008 01:53:48 -0000 Received: (qmail 31300 invoked by uid 22791); 9 May 2008 01:53:44 -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 01:53:25 +0000 Received: (qmail 3767 invoked from network); 9 May 2008 01:53:23 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 9 May 2008 01:53:23 -0000 From: Pedro Alves To: gdb-patches@sourceware.org, Eli Zaretskii Subject: Re: [RFC] 10/10 non-stop for linux native Date: Fri, 09 May 2008 03:25:00 -0000 User-Agent: KMail/1.9.9 References: <200805061650.10912.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805090253.21680.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/msg00301.txt.bz2 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. You can also see similar results by: sudo cat /proc/10/mem cat: /proc/10/mem: No such process > If we are, isn't it better to solve these bugs in > ptrace first? And if we do work around these bugs as suggested in > this patch, won't that be a maintenance burden once the kernel people > start fixing it in some future Linux version? > Not really. If the kernel was "fixed", the code I'm adding should still work. Plus, most of what I'm adding are not workarounds. I don't think this patch and the "extra maintenance burden" is significant enough to warrant any ptrace redesign on the kernel side, and requiring everyone to upgrade their kernels to have access to non-stop. Plus, other ptrace OSs should have the same issues, even the closed-source ones. > Sorry if these are silly questions out of ignorance. Not at all. -- Pedro Alves