From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28612 invoked by alias); 12 Nov 2008 21:22:42 -0000 Received: (qmail 28573 invoked by uid 22791); 12 Nov 2008 21:22:41 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-2.vmware.com (HELO smtp-outbound-2.vmware.com) (65.115.85.73) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 12 Nov 2008 21:22:04 +0000 Received: from mailhost2.vmware.com (mailhost2.vmware.com [10.16.67.167]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id CA33031000; Wed, 12 Nov 2008 13:22:02 -0800 (PST) Received: from [10.20.92.59] (promb-2s-dhcp59.eng.vmware.com [10.20.92.59]) by mailhost2.vmware.com (Postfix) with ESMTP id B03428E55D; Wed, 12 Nov 2008 13:22:02 -0800 (PST) Message-ID: <491B48F7.5030407@vmware.com> Date: Wed, 12 Nov 2008 21:22:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Stan Shebs CC: "pedro@codesourcery.com" , "gdb@sourceware.org" Subject: Re: multi-proc: info processes? References: <491B3695.5090300@vmware.com> <491B3A6E.5010208@codesourcery.com> In-Reply-To: <491B3A6E.5010208@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 X-SW-Source: 2008-11/txt/msg00094.txt.bz2 Stan Shebs wrote: > Michael Snyder wrote: >> Hey Pedro, >> >> For your multi-process work, are you planning anything >> analogous to the "info threads" command, eg. "info processes"? > Look at "info inferiors". It's just the processes (or whatever) that are > currently being controlled by GDB. >> What might that look like, in your model? Would it list, >> say, just the processes that gdb is attached to? Or would >> you want something analogous to "ps", that would list all >> of the processes that are available to be attached? > That would be somewhat ambitious, especially for a remote target - I > think you'd need a new packet just to return the list of processes... Sure -- by analogy with qfThreadInfo/qsThreadInfo, it could be implemented as an iterator. I'm not sure how desireable it is, but it could save you from having to go over to the remote target and typing "ps"... By the way, what about remote attach? Is that in the plan?