From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23027 invoked by alias); 13 Nov 2008 01:48:33 -0000 Received: (qmail 22541 invoked by uid 22791); 13 Nov 2008 01:48:30 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-1.vmware.com (HELO smtp-outbound-1.vmware.com) (65.115.85.69) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 13 Nov 2008 01:47:45 +0000 Received: from mailhost4.vmware.com (mailhost4.vmware.com [10.16.67.124]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id E797121004; Wed, 12 Nov 2008 17:47:43 -0800 (PST) Received: from [10.20.92.59] (promb-2s-dhcp59.eng.vmware.com [10.20.92.59]) by mailhost4.vmware.com (Postfix) with ESMTP id DD186C9A58; Wed, 12 Nov 2008 17:47:43 -0800 (PST) Message-ID: <491B873A.9010705@vmware.com> Date: Thu, 13 Nov 2008 01:48:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Pedro Alves CC: Stan Shebs , "gdb@sourceware.org" Subject: Re: multi-proc: info processes? References: <491B3695.5090300@vmware.com> <491B3A6E.5010208@codesourcery.com> <491B48F7.5030407@vmware.com> <200811122129.59949.pedro@codesourcery.com> In-Reply-To: <200811122129.59949.pedro@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/msg00098.txt.bz2 Pedro Alves wrote: > On Wednesday 12 November 2008 21:21:59, Michael Snyder wrote: >> 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. > > Yeah, there are many ways to implement that. Both Vladimir and > I ended up doing that independently but similarly, by querying a new > enum target_object and having the stub formatting the list of > processes as xml. Vladimir has the ball on merging those > currently --- let's see what comes out, might even pop out something > totally different. :-) Hmmm, isn't the formatting of xml a little heavy-weight for a stub? Stubs are traditionally sort of light-weight entities. I realize we're really talking about a gdbserver-type entity here... Just for yuks, what about something like this, again by analogy to info threads? Query: qfProcInfo (f for 'first') Reply: m Query: qsProcInfo (s for... umm, 'next') Reply: m, or 'l' if this is the 'last' reply. Of course, then you might want some analog of "ExtraInfo"...