From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16995 invoked by alias); 8 May 2008 11:48:29 -0000 Received: (qmail 16987 invoked by uid 22791); 8 May 2008 11:48:28 -0000 X-Spam-Check-By: sourceware.org Received: from mtaout6.012.net.il (HELO mtaout6.012.net.il) (84.95.2.16) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 08 May 2008 11:48:08 +0000 Received: from HOME-C4E4A596F7 ([83.130.255.47]) by i-mtaout6.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0K0J00J9VTFX2UU0@i-mtaout6.012.net.il> for gdb-patches@sourceware.org; Thu, 08 May 2008 15:02:22 +0300 (IDT) Date: Thu, 08 May 2008 18:30:00 -0000 From: Eli Zaretskii Subject: Re: [RFC] 10/10 non-stop for linux native In-reply-to: <200805061650.10912.pedro@codesourcery.com> X-012-Sender: halo1@inter.net.il To: Pedro Alves Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: References: <200805061650.10912.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/msg00280.txt.bz2 > 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? 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? Sorry if these are silly questions out of ignorance.