From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11634 invoked by alias); 21 May 2013 13:15:51 -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 11622 invoked by uid 89); 21 May 2013 13:15:51 -0000 X-Spam-SWARE-Status: No, score=-5.8 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; Tue, 21 May 2013 13:15:49 +0000 Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r4LDFipx023810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 May 2013 09:15:45 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Tue, 21 May 2013 09:15:14 -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 r4LDFC7S018449; Tue, 21 May 2013 09:15:12 -0400 Received: by usendtaylorx2l.lss.emc.com (Postfix, from userid 26043) id 568C15AFECB; Tue, 21 May 2013 09:15:10 -0400 (EDT) Received: from usendtaylorx2l (localhost [127.0.0.1]) by usendtaylorx2l.lss.emc.com (Postfix) with ESMTP id D27795AFEC3; Tue, 21 May 2013 09:15:10 -0400 (EDT) To: Yao Qi cc: "gdb@sourceware.org" Subject: Re: add-inferior / clone-inferior In-reply-to: <519AC76E.4040508@codesourcery.com> References: <7249.1369061005@usendtaylorx2l> <519AC76E.4040508@codesourcery.com> Comments: In-reply-to Yao Qi message dated "Mon, 20 May 2013 21:01:34 -0400." Date: Tue, 21 May 2013 13:15:00 -0000 Message-ID: <20412.1369142110@usendtaylorx2l> From: David Taylor X-EMM-MHVC: 1 X-SW-Source: 2013-05/txt/msg00091.txt.bz2 Yao Qi wrote: >On 05/20/2013 10:43 PM, David Taylor wrote: >David, >GDB supports multiple inferiors in a single remote target (in >extended-remote mode). GDB can't talk with multiple remote targets in >parallel so far. What you need/want is GDB talks with multiple remote >targets (GDBserver on different boards). I want to have separate sockets at GDB's end. I do not want to have a "meta stub" (not really a good name, but nothing better quickly comes to mind) on the local box that managers tcp connections and peeks into the packets to determine when to set up or break down a new tcp connection and where to send the packets. That is, I do not want to do: target extended-remote | And then have look at the contents of each an every packet to decide whether it is something for it to act on or something to forward on. THat approach is UGLY. Each remote end is a separate kernel. >> I'm also thinking that target_ops needs to have a couple of additional fields: >> >> . a boolean -- does the target support multiple concurrent active >> instances? >> >> . a counter -- how many active instances do we currently have? >> > >What do you mean by "instance" here? a process on a target board >physically? It's a reference counter -- it's how many inferiors (as shown by, say, info inferiors) have this target as their target. If the first field is false -- the target does not support concurrent active instances -- then the counter effectively becomes a boolean -- is there currently an inferior with this target as its target? >> p.s. It would also be nice if inferiors could be named, otherwise >> you'll end up creating a crib sheet telling you which is which. It's >> trivial, but it makes me think that no one really uses add-inferior / >> clone-inferior. > >In terms of naming, we are proposing ITSET (inferior/thread set) or >PTSET (process/thread set) to GDB >. With >ITSET, you can name a set of inferiors: > >(gdb) defset foo i1-2 // define named itset 'foo' for inferior 1 and 2 >(gdb) defset bar i3-4 // define named itset 'foo' for inferior 3 and 4 > >and you can apply command to named set via proposed command 'scope': > >// detach from inferiors in set 'foo'. >(gdb) scope foo detach >// check the stack backtrace of inferiors in set 'bar'. >(gdb) scope bar bt >// generate corefile for each process in set 'foo' and 'bar'. >(gdb) scope bar,foo gcore > >Hope ITSET is helpful on your naming issue. I think that having named sets of the inferiors would be useful as well. With an inferior potentially being a member in zero or more sets. And you could think of names as being sets with unique elements. But, I was thinking of something simpler -- a unique user settable field that shows up when you do 'info inferiors' or the like -- that could, hopefully, be used anywhere that the existing ID is used.