From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8145 invoked by alias); 22 May 2013 19:42:45 -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 8135 invoked by uid 89); 22 May 2013 19:42:45 -0000 X-Spam-SWARE-Status: No, score=-5.9 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.1 Received: from hop-nat-141.emc.com (HELO mexforward.lss.emc.com) (168.159.213.141) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 22 May 2013 19:42:44 +0000 Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r4MJgYDv004929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 May 2013 15:42:40 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Wed, 22 May 2013 15:42:18 -0400 Received: from usendtaylorx2l.lss.emc.com (usendtaylorx2l.lss.emc.com [10.243.10.188]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r4MJgICp020767; Wed, 22 May 2013 15:42:18 -0400 Received: by usendtaylorx2l.lss.emc.com (Postfix, from userid 26043) id 15C205B0261; Wed, 22 May 2013 15:42:16 -0400 (EDT) Received: from usendtaylorx2l (localhost [127.0.0.1]) by usendtaylorx2l.lss.emc.com (Postfix) with ESMTP id 8C1765B0256; Wed, 22 May 2013 15:42:16 -0400 (EDT) To: Tom Tromey cc: "gdb@sourceware.org" Subject: Re: add-inferior / clone-inferior In-reply-to: <87k3mqhmsn.fsf@fleche.redhat.com> References: <7249.1369061005@usendtaylorx2l> <87bo84l5ad.fsf@fleche.redhat.com> <87ehczhy0c.fsf@fleche.redhat.com> <8702.1369246895@usendtaylorx2l> <87k3mqhmsn.fsf@fleche.redhat.com> Comments: In-reply-to Tom Tromey message dated "Wed, 22 May 2013 14:50:00 -0400." Date: Wed, 22 May 2013 19:42:00 -0000 Message-ID: <9342.1369251736@usendtaylorx2l> From: David Taylor X-EMM-MHVC: 1 X-SW-Source: 2013-05/txt/msg00104.txt.bz2 Tom Tromey wrote: > Tom> One that comes to mind is what target is associated with an inferior > Tom> created with add-inferior? How could you change this inferior's target > Tom> to connect it to some existing target? > > David> Perhaps I misunderstand the question. Initially, there is just a dummy > David> target. > > David> Do a command like 'file' and you have an exec target. > > David> Do a command like 'run' or 'attach' or 'target remote' or 'target > David> extended-remote' and your process stratum target is pushed on top of the > David> old file stratum target. > > David> Do a command like 'kill' or 'detach' and your process stratum target is > David> popped and you are back at the exec stratum target -- the exec file -- > David> at the top of your target stack. > > I was thinking of a scenario like: I have an existing connection to an > extended-remote target, then I want to add an inferior and then run it > on that target. > > I guess something like this would work if "target extended-remote" > always did connection sharing: > > add-inferior -exec whatever > target extended-remote server:port > run > > The issue I have is differentiating this from the scenario of: add > inferior, connect for the first time, then try to run. Won't this do > something different if the remote is already running? > > I feel like I'm confused somehow. I wasn't thinking about that scenario. My current interest is talking to the kernel of a machine that might be in a local lab or might be at a customer site half way around the world. The existing kernel stub does not multiplex between boards. Each board has its own kernel. If you want to multiplex between kernels, you have to do it at a higher level. I'd rather not have an intermediate server that inspects the packets, acts on some and passes the others on. But, if you give it a different server:port than previously, presumably you want it to open a new connection. I think it needs to be clear to the user whether it is reusing an existing connection or creating a new one. Perhaps a different syntax than server:port when reusing a connection? Maybe, target extended-remote @ with an empty [i.e., just '@' for an argument] meaning use the current inferior. Unless you think that a user would always do one or always do the other, rarely switching, in which case perhaps a settable flag would be appropriate? > David> . you want to know the full set of inferiors and their targets. > > David> Seems somewhat esoteric. Perhaps a maint command would be appropriate? > > I suppose we could just print it in "info inferiors". If we just printed the top stratum element putting it into info inferiors is probably reasonable. If it was more verbose, I don't think the average user would care to see it. I'd also like a name field somewhere for the inferior. I can envision debugging a client server problem by having both under one GDB rather than two GDBs. Ideally, names that the 'inferior' command recognizes in addition to a numeric inferior id. Then I could do inferior client ... some commands ... inferior server ... some commands ... > Tom David