Re: [rfc/rfa] [4/4] SPU enhancements: GDB/MI extensions

[Ricardo Marin Matinata <matinata at br dot ibm dot com>]

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