From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14736 invoked by alias); 21 May 2013 01:01:25 -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 14726 invoked by uid 89); 21 May 2013 01:01:24 -0000 X-Spam-SWARE-Status: No, score=-4.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL autolearn=ham version=3.3.1 Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 21 May 2013 01:01:21 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1Ueax5-0001Cr-Jb from Yao_Qi@mentor.com ; Mon, 20 May 2013 18:01:19 -0700 Received: from SVR-ORW-FEM-03.mgc.mentorg.com ([147.34.97.39]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 May 2013 18:01:19 -0700 Received: from qiyao.dyndns.org (147.34.91.1) by svr-orw-fem-03.mgc.mentorg.com (147.34.97.39) with Microsoft SMTP Server id 14.2.247.3; Mon, 20 May 2013 18:01:18 -0700 Message-ID: <519AC76E.4040508@codesourcery.com> Date: Tue, 21 May 2013 01:01:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: David Taylor CC: Subject: Re: add-inferior / clone-inferior References: <7249.1369061005@usendtaylorx2l> In-Reply-To: <7249.1369061005@usendtaylorx2l> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2013-05/txt/msg00087.txt.bz2 On 05/20/2013 10:43 PM, David Taylor wrote: > The commands add-inferior / clone-inferior and several related commands > were added as long ago as gdb 7.1. But, unless I'm missing the obvious, > they aren't currently very useful. > > GDB appears to support multiple "live" inferiors only when the arise as > the result of a fork or vfork. Please tell me that I'm wrong and that > I'm missing the obvious. > > . I start up gdb with no arguments > . file my-elf-file > . clone-inferior > . info inferiors > > I now have two inferiors, numbers 1 and 2, same elf file; 1 is curent. > > . target remote > . inferior 2 > . target remote > > And I get: > > A program is being debugged already. Kill it? (y or n) > > I also tried attaching to two pre-existing processes, one each two > different inferiors. That failed as well. 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've looked more at remote targets than attached / forked targets, as we > are more interested in remote targets. Thursday last week I would have > loved to have had 10 inferiors, 5 elf files, 2 inferiors per elf file. > > Looking at remote.c, it stores a global pointer to a structure > containing a file descriptor and other state in remote_desc. > > This variable, and presumably others, are inferior specific. > > Looking at inferior.h I see: > > /* Private data used by the target vector implementation. */ > struct private_inferior *private; > > Based on the comment, the structure should probably be called > private_target rather than private_inferior. > > I'm thinking that remote.c should define a struct private_inferior > containing, at least, a pointer to 'struct serial *remote_desc' and then > *EITHER* changing inferiors needs to save / restore remote_desc (which > would mean target_ops entries for { saving / restoring } state when you > { switch away from / switch back to } an inferior *OR* all references to > remote_desc need to be modified to get to it via > > current_inferior -> private -> remote_desc -> ... > Probably, each inferior should be ref-count'ed the remote_desc, because multiple inferiors may share the same remote_desc, and the connection leak can be avoided. I am not the people design and write this part of code, but I don't see something wrong in your thoughts. > 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? > > 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. -- Yao (齐尧)