From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13244 invoked by alias); 21 Jun 2007 02:23:47 -0000 Received: (qmail 13220 invoked by uid 22791); 21 Jun 2007 02:23:46 -0000 X-Spam-Check-By: sourceware.org Received: from igw2.br.ibm.com (HELO igw2.br.ibm.com) (32.104.18.25) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 21 Jun 2007 02:23:44 +0000 Received: from mailhub1.br.ibm.com (mailhub1 [9.18.232.109]) by igw2.br.ibm.com (Postfix) with ESMTP id AF78A5BD8F for ; Wed, 20 Jun 2007 23:14:26 -0300 (BRT) Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.18.232.46]) by mailhub1.br.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l5L2Ndlx1622258 for ; Wed, 20 Jun 2007 23:23:39 -0300 Received: from d24av01.br.ibm.com (loopback [127.0.0.1]) by d24av01.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l5L2L7vu002966 for ; Wed, 20 Jun 2007 23:21:07 -0300 Received: from [9.67.190.30] (wecm-9-67-190-30.wecm.ibm.com [9.67.190.30]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l5L2L4JC002957; Wed, 20 Jun 2007 23:21:05 -0300 Subject: Re: [rfc/rfa] [4/4] SPU enhancements: GDB/MI extensions From: Ricardo Marin Matinata Reply-To: matinata@br.ibm.com To: Ulrich Weigand Cc: Daniel Jacobowitz , gdb-patches@sourceware.org, eliz@gnu.org In-Reply-To: <200706142004.l5EK4vTO021141@d12av02.megacenter.de.ibm.com> References: <200706142004.l5EK4vTO021141@d12av02.megacenter.de.ibm.com> Content-Type: text/plain Date: Thu, 21 Jun 2007 02:23:00 -0000 Message-Id: <1182392605.4974.58.camel@rmm-tp> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit 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/msg00407.txt.bz2 On Thu, 2007-06-14 at 22:04 +0200, Ulrich Weigand wrote: > Daniel Jacobowitz wrote: > > On Tue, Jun 05, 2007 at 12:59:20AM +0200, Ulrich Weigand wrote: > > > Daniel Jacobowitz wrote: > > > > > > > Right, but I didn't mean something quite that ambitious. What does > > > > the IDE end up doing with the output of these commands, and does it > > > > want to parse them or just display them as text? > > > > > > It certainly parses the information for display; for example, the > > > -spu-info-dma command results in output like (added whitespace for > > > better readability): > > > > > > (gdb) > > > -spu-info-dma > > > ^done,SPUInfoDMA= > > > { > > > dma_info_type="0x0", > > > dma_info_mask="0x20", > > > dma_info_status="0x0", > > > > OK. One way we could display this would be as a "struct" and with a > > varobj. > > > > I can't really explain why I think target-specific MI commands are a > > bad idea. Maybe they aren't; I'd love to hear other people's > > opinions. I worry a bit about GDB/MI diverging between targets. > > > > > It would appear that this makes sense only if the IDE is capable of > > > generically displaying any such -arch-info output. This is a bit > > > different from our current -spu-info implementation where the IDE > > > has its own understanding of each of the various commands, and how > > > to best display the result of each of them. > > > > Not necessarily. I hope it would make sense if the IDE is capable of > > generic display, even if it is also capable of more specific display. > > Or it may just be a horrible idea. > > I'd like to get Ricardo Matinata, our Cell/B.E. IDE team lead, involved > in this discussion, to make sure the format will be useful to them. > > Ricardo, what are your thoughts on a generic -arch-info command as > suggested by Dan? How would this need to look like to allow you > to present the "info spu" information in the same way (or at least > with the same ease-of-use) to the user? > > Bye, > Ulrich > So, roughly, a spu-info-dma would be transformed in to something like this: -arch-info dma ^done (gdb) -arch-info-list-children dma ^done,numchild="6",children=[child={name="dma.type",exp="type", numchild="0",type="int"},child={name="dma.mask",exp="mask", numchild="0",type="int"},child={name="dma.status",exp="status", numchild="0",type="int"},child={name="dma.stall_and_notify", exp="stall_and_notify",numchild="0",type="int"},child={name="dma.atomic_command_status",exp="atomic_command_status",numchild="0",type="int"},child={name="dma.cmd",exp="cmd",numchild="16",type="struct"}] -arch-info-evaluate-expression dma.type (gdb) ^done,value="0x0" -arch-info-evaluate-expression dma.mask (gdb) ^done,value="0x0" -arch-info-evaluate-expression dma.status (gdb) ^done,value="0x0" -arch-info-evaluate-expression dma.stall_and_notify (gdb) ^done,value="0x0" -arch-info-evaluate-expression dma.atomic_command_status (gdb) ^done,value="0x0" -arch-info-list-children dma.cmd ^done,numchild="16",children=[child={name="dma.cmd.getl",exp="getl", numchild="9",type="struct"},child={name="dma.cmd.putllc", exp="putllc",numchild="9",type="struct"},child={name="dma.cmd.get", exp="get1",numchild="9",type="struct"},child={name="dma.cmd. mfcsync",exp="mfcsync",numchild="9",type="struct"},child={name="dma.cmd.get2",exp="get2",numchild="9",type="struct"},........] .............. >From the arch independence point of view there's no much to add to what has already been said. However, please allow me to add a couple of points to the usability and display representation issues: - With the new proposed approach, arch specific mi commands would behave much like the var-objs commands. In Eclipse's case, var-objs are handled by the Expressions View, which is basically a Tree-List widget. This also would be the reasonable way to render the output of these arch-info specific commands, and hence, for a hairy nested structure like this dma one, would end up requiring a few clicks from the user to actually visualize the information, as opposed to the always visible combination of Table widgets that we have in the current implementation. - At each OOB event, Eclipse tries to keep all the visible debug views (expression, memory, registers, breakpoints...) updated, so it re-issues the respective commands in order to accomplish that. With the example here, depending on how deep the user had expanded the supposed Tree-List representation, we are talking about 5/6 commands to refresh a "leaf" value. All said, i guess, maybe, the best of both worlds (the one that is already implemented for spu and the var-objs-like one) could be contemplated. In addition to giving a var-objs nature for the arch-info dependent commands, where we have to basically navigate thru the output information structure, i would also suggest the inclusion of a one-shot "straight" output dump command, something like -arch-info-dump "dma",at least for those who still prefer a more "static" specific GUI representation for these commands' output. Hope these helped. Best Regards, -- Ricardo M. Matinata Linux on Cell/B.E. Development matinata@br.ibm.com