From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2682 invoked by alias); 22 May 2013 20:21:19 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 2673 invoked by uid 89); 22 May 2013 20:21:18 -0000 X-Spam-SWARE-Status: No, score=-6.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 22 May 2013 20:21:14 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r4MKLBn4003319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 22 May 2013 16:21:11 -0400 Received: from barimba (ovpn-113-72.phx2.redhat.com [10.3.113.72]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r4MKL9Rj005503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 22 May 2013 16:21:10 -0400 From: Tom Tromey To: David Taylor Cc: "gdb\@sourceware.org" Subject: Re: add-inferior / clone-inferior References: <7249.1369061005@usendtaylorx2l> <87bo84l5ad.fsf@fleche.redhat.com> <87ehczhy0c.fsf@fleche.redhat.com> <8702.1369246895@usendtaylorx2l> <87k3mqhmsn.fsf@fleche.redhat.com> <9342.1369251736@usendtaylorx2l> Date: Wed, 22 May 2013 20:21:00 -0000 In-Reply-To: <9342.1369251736@usendtaylorx2l> (David Taylor's message of "Wed, 22 May 2013 15:42:16 -0400") Message-ID: <87sj1eg40a.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-05/txt/msg00106.txt.bz2 David> I wasn't thinking about that scenario. My current interest is talking David> to the kernel of a machine that might be in a local lab or might be at a David> customer site half way around the world. Yeah. I'm just brainstorming different scenarios to try to understand what problems multi-target might have. Running a new program via an extended-remote gdbserver seems like a reasonable thing to want to do; but I wasn't sure of the mechanics. David> But, if you give it a different server:port than previously, presumably David> you want it to open a new connection. I think it needs to be clear to David> the user whether it is reusing an existing connection or creating a new David> one. Perhaps a different syntax than server:port when reusing a David> connection? Yeah, that may be the way to go. Or maybe "always reuse" is best? Since it seems unlikely to want to open multiple concurrent connections to the exact same server/port pair. (I guess it could work with some hypothetical gdbserver. But I don't think it exists.) David> If we just printed the top stratum element putting it into info David> inferiors is probably reasonable. If it was more verbose, I don't think David> the average user would care to see it. I was just thinking something like: (gdb) info inferior Num Description Executable Target * 1 process 2994 /usr/bin/gdb native 2 process 1222 /bin/sh server:9999 David> I'd also like a name field somewhere for the inferior. I can envision David> debugging a client server problem by having both under one GDB rather David> than two GDBs. Ideally, names that the 'inferior' command recognizes David> in addition to a numeric inferior id. Then I could do David> inferior client David> ... some commands ... David> inferior server David> ... some commands ... IT sets were the answer to this in the past, but I see in your other mail that you also wanted it to show up in "info inferiors". That seems reasonable to me; though maybe it could be some kind of itset flag. I think Pedro and Yao have the best status on itsets. Tom