From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23579 invoked by alias); 13 Nov 2008 23:19:13 -0000 Received: (qmail 23541 invoked by uid 22791); 13 Nov 2008 23:19:13 -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; Thu, 13 Nov 2008 23:18:36 +0000 Received: from mailhost2.vmware.com (mailhost2.vmware.com [10.16.67.167]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 981E61E005; Thu, 13 Nov 2008 15:18:33 -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 805738E570; Thu, 13 Nov 2008 15:18:33 -0800 (PST) Message-ID: <491CB5BA.7060807@vmware.com> Date: Thu, 13 Nov 2008 23:19:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Michael Snyder , Pedro Alves , 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> <491B873A.9010705@vmware.com> <20081113045618.GA12133@caradoc.them.org> In-Reply-To: <20081113045618.GA12133@caradoc.them.org> 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/msg00111.txt.bz2 Daniel Jacobowitz wrote: > On Wed, Nov 12, 2008 at 05:47:38PM -0800, Michael Snyder wrote: >> Hmmm, isn't the formatting of xml a little heavy-weight for a stub? > > Nope. *Parsing* XML is a bit heavy-weight, but generating it requires > only a tiny routine to escape characters if you support arbitrary > names in the generated XML; you can generate it textually, not > via a DOM. gdbserver does this, for instance, and I'd guess it's just > a couple hundred bytes of code. No more than it would take for a > qfThreadInfo analogue. OK. Could I maybe get a preview of what you have in mind? I'm working on something similar, might as well try to be compatible.