From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23077 invoked by alias); 19 Sep 2008 15:32:39 -0000 Received: (qmail 23059 invoked by uid 22791); 19 Sep 2008 15:32:38 -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, 19 Sep 2008 15:31:44 +0000 Received: (qmail 6687 invoked from network); 19 Sep 2008 15:31:42 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 19 Sep 2008 15:31:42 -0000 From: Pedro Alves To: Daniel Jacobowitz Subject: Re: [RFA 03/08] multi-process support: remote multi-process extensions Date: Fri, 19 Sep 2008 15:32:00 -0000 User-Agent: KMail/1.9.9 Cc: gdb-patches@sourceware.org References: <200809121638.59063.pedro@codesourcery.com> <200809121751.30596.pedro@codesourcery.com> <20080918232439.GE1691@caradoc.them.org> In-Reply-To: <20080918232439.GE1691@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809191632.05874.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-09/txt/msg00414.txt.bz2 On Friday 19 September 2008 00:24:39, Daniel Jacobowitz wrote: > On Fri, Sep 12, 2008 at 05:51:30PM +0100, Pedro Alves wrote: > > 2008-09-12 Pedro Alves > > > > Implement multi-process extensions. > > This looks basically OK to me. I've got one question, which is not > bad for a patch this size :-) Yay! :-) > What about "target remote" vs "target extended-remote"? Are you > always expected to use target extended-remote to connect to a > multi-process target, and if so, should we enforce that? Or are > remote and extended-remote supposed to behave the same if the target > is multi-process? Good question. Originally, it was meant to only be used by extended-remote. [cross reference for the archives: http://sourceware.org/ml/gdb/2008-05/msg00166.html] But maybe we can try to do something that is sensible with target remote. I can imagine attaching with "target remote" to a stub that was already debugging multiple things (disconnect/connect, for instance). You wont be able to run new processes, but, you'll be able to see what was already there. > I ask because of the change in remote_detach_1. If > rs->multi_process_aware is set, we never unregister from > the target. But we call target_mourn_inferior which will unpush the > remote target in that case. Yeah. I can imagine making use of these extensions for simple multi-core configurations, where detaching from a single core doesn't make that much sense. How about we still send the older 'D' packet when in "target remote", and leave 'D;pid' "target extended-remote"? That would mirror vAttach. I'm already sending 'k' in "target remote" instead of 'vKill', even if multi-process. A multi-process aware stub would them detach from processes (or something else exported as processes to gdb) when seeing 'D'. I'm already applying similar logic to target_kill/'k'/'vKill'. I just noticed a bug I had fixed in an internal tree, that I forgot adding to this patch. "info threads" in addition to adding threads to the thread list, should also add inferiors to the inferior list (e.g., disconnect/connect). -- Pedro Alves