From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12064 invoked by alias); 20 Jul 2010 19:41:35 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 12052 invoked by uid 22791); 20 Jul 2010 19:41:34 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Oleg Nesterov Cc: Jan Kratochvil , archer@sourceware.org Subject: Re: Q: mutlithreaded tracees && clone/exit In-Reply-To: Oleg Nesterov's message of Tuesday, 20 July 2010 15:16:15 +0200 <20100720131615.GA17450@redhat.com> References: <20100718174851.GA15528@redhat.com> <20100716205147.GA26313@redhat.com> <20100719160127.GA13331@host1.dyn.jankratochvil.net> <20100720131615.GA17450@redhat.com> Message-Id: <20100720194119.C0E3C40162@magilla.sf.frob.com> Date: Tue, 20 Jul 2010 19:41:00 -0000 X-SW-Source: 2010-q3/txt/msg00049.txt.bz2 > Probably this is fine for gdb. But ugdb was started to prototype the > new general purpose API. Say, vAttach attaches the whole thread group, > there is no way to debug a single thread. Not good in general. The same > for D command and for W/X notifications from gdbserver. It seems fine and normal for whole process to be the granularity of attaching. You need to be able to control the individual threads, of course. But it doesn't really make a lot of sense to "debug" one thread and not another in the same process. > However, when this thread exits, gdbserver sends nothing and gdb > continues to wait. For what? Another (main) thead is TASK_TRACED, > it can do nothing unless it is SIGKILLED. Yes, it seems like gdb is confusing itself here. Perhaps it is not confused that way when in non-stop mode. Thanks, Roland