From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15627 invoked by alias); 4 Jun 2007 20:00:47 -0000 Received: (qmail 15617 invoked by uid 22791); 4 Jun 2007 20:00:46 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 04 Jun 2007 20:00:44 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id CD2DE982E4; Mon, 4 Jun 2007 20:00:42 +0000 (GMT) Received: from caradoc.them.org (dsl093-172-095.pit1.dsl.speakeasy.net [66.93.172.95]) by nan.false.org (Postfix) with ESMTP id 6E9C5982E2; Mon, 4 Jun 2007 20:00:42 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.67) (envelope-from ) id 1HvIiu-0006Y4-G9; Mon, 04 Jun 2007 16:00:16 -0400 Date: Mon, 04 Jun 2007 20:00:00 -0000 From: Daniel Jacobowitz To: Ulrich Weigand Cc: gdb-patches@sourceware.org, eliz@gnu.org Subject: Re: [rfc/rfa] [4/4] SPU enhancements: GDB/MI extensions Message-ID: <20070604200016.GD23516@caradoc.them.org> Mail-Followup-To: Ulrich Weigand , gdb-patches@sourceware.org, eliz@gnu.org References: <200706021934.l52JY1ZD005660@d12av02.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200706021934.l52JY1ZD005660@d12av02.megacenter.de.ibm.com> User-Agent: Mutt/1.5.15 (2007-04-09) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-06/txt/msg00039.txt.bz2 On Sat, Jun 02, 2007 at 09:34:01PM +0200, Ulrich Weigand wrote: > Hello, > > this patch makes the new "info spu" commands available via the GDB/MI > protocol. The Cell Broadband Engine IDE is already able to make use > of these commands and display the SPU status information. > > It looks like these are the first platform-specific MI commands, so > I'd appreciate opinions on this ... The documentation doesn't say what the output should be; we need that for consumers to parse it usefully. Does it get MI-tabulated? If not, there's always -interpreter-exec. I mentioned in an earlier message that it would be nice if this sort of output was more generic, so that it could come straight from a target description file without a lot of tdep code. That's easy to put off to another day, but the same thing applies to GDB's conversation with consumers. Is there some less target-specific way that we can present this information? For instance, a way that an IDE could automatically pick up all the target-specific data that GDB knows about without the IDE having to know about all of it also. That doesn't mean the IDE can't know about it too, of course, to provide more specialized access. If we do go ahead with these new commands I suggest you add a test case for them. -- Daniel Jacobowitz CodeSourcery