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

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

[Nick Roberts]

On Sat, 2 Jun 2007 21:34:01 +0200 (CEST) Ulrich Weigand writes:
>...
> ChangeLog:

> 	* mi/mi-cmds.c (mi_cmds): Add -spu-info-event, -spu-info-signal,
> 	-spu-info-mailbox, -spu-info-dma, and -spu-info-proxydma commands.

> doc/ChangeLog:

> 	* gdb.texinfo (GDB/MI Miscellaneous Commands): Document -spu-info
> 	commands.


I don't think the description of these command belongs to the node
GDB/MI Miscellaneous Commands, but a node of it's own within a new node
called something like "GDB/MI Architecture Specific Commands".

Also I agree with Daniel J's remarks about a MI command like -arch-info.  I
don't know if general purpose software like Emacs could run on the Cell
Broadband Engine, but without such a command, presumably the above ones are
enhancements of GDB for the Cell Broadband Engine IDE only.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

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

[Ulrich Weigand]

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 ...

Eli, doc changes OK?

Bye,
Ulrich


ChangeLog:

	* mi/mi-cmds.c (mi_cmds): Add -spu-info-event, -spu-info-signal,
	-spu-info-mailbox, -spu-info-dma, and -spu-info-proxydma commands.

doc/ChangeLog:

	* gdb.texinfo (GDB/MI Miscellaneous Commands): Document -spu-info
	commands.


diff -urNp gdb-orig/gdb/doc/gdb.texinfo gdb-head/gdb/doc/gdb.texinfo
--- gdb-orig/gdb/doc/gdb.texinfo	2007-05-31 18:54:31.000000000 +0200
+++ gdb-head/gdb/doc/gdb.texinfo	2007-06-02 20:02:13.954945166 +0200
@@ -21155,6 +21155,86 @@ fullname="/home/nickrob/myprog.c",line="
 (gdb)
 @end smallexample
 
+@subheading The @code{-spu-info-event} Command
+@findex -spu-info-event
+
+@subheading Synopsis
+
+@smallexample
+-spu-info-event
+@end smallexample
+
+Display SPU event facility status.  This command is available only
+when @value{GDBN} is debugging the Cell Broadband Engine SPU architecture.
+
+@subheading @value{GDBN} Command
+
+The corresponding @value{GDBN} command is @samp{info spu event}.
+
+@subheading The @code{-spu-info-signal} Command
+@findex -spu-info-signal
+
+@subheading Synopsis
+
+@smallexample
+-spu-info-signal
+@end smallexample
+
+Display SPU signal notification facility status.  This command is available
+only when @value{GDBN} is debugging the Cell Broadband Engine SPU architecture.
+
+@subheading @value{GDBN} Command
+
+The corresponding @value{GDBN} command is @samp{info spu signal}.
+
+@subheading The @code{-spu-info-mailbox} Command
+@findex -spu-info-mailbox
+
+@subheading Synopsis
+
+@smallexample
+-spu-info-mailbox
+@end smallexample
+
+Display SPU mailbox facility status.  This command is available only when
+@value{GDBN} is debugging the Cell Broadband Engine SPU architecture.
+
+@subheading @value{GDBN} Command
+
+The corresponding @value{GDBN} command is @samp{info spu mailbox}.
+
+@subheading The @code{-spu-info-dma} Command
+@findex -spu-info-dma
+
+@subheading Synopsis
+
+@smallexample
+-spu-info-dma
+@end smallexample
+
+Display MFC DMA status.  This command is available only when @value{GDBN}
+is debugging the Cell Broadband Engine SPU architecture.
+
+@subheading @value{GDBN} Command
+
+The corresponding @value{GDBN} command is @samp{info spu dma}.
+
+@subheading The @code{-spu-info-proxydma} Command
+@findex -spu-info-proxydma
+
+@subheading Synopsis
+
+@smallexample
+-spu-info-proxydma
+@end smallexample
+
+Display MFC Proxy-DMA status.  This command is available only when
+@value{GDBN} is debugging the Cell Broadband Engine SPU architecture.
+
+@subheading @value{GDBN} Command
+
+The corresponding @value{GDBN} command is @samp{info spu proxydma}.
+
 @node Annotations
 @chapter @value{GDBN} Annotations
 
diff -urNp gdb-orig/gdb/mi/mi-cmds.c gdb-head/gdb/mi/mi-cmds.c
--- gdb-orig/gdb/mi/mi-cmds.c	2007-05-09 00:47:48.000000000 +0200
+++ gdb-head/gdb/mi/mi-cmds.c	2007-06-02 20:03:01.093198140 +0200
@@ -100,6 +100,11 @@ struct mi_cmd mi_cmds[] =
   { "signal-handle", { NULL, 0 }, NULL, NULL },
   { "signal-list-handle-actions", { NULL, 0 }, NULL, NULL },
   { "signal-list-signal-types", { NULL, 0 }, NULL, NULL },
+  { "spu-info-event", { "info spu event", 0 }, NULL, NULL },
+  { "spu-info-signal", { "info spu signal", 0 }, NULL, NULL },
+  { "spu-info-mailbox", { "info spu mailbox", 0 }, NULL, NULL },
+  { "spu-info-dma", { "info spu dma", 0 }, NULL, NULL },
+  { "spu-info-proxydma", { "info spu proxydma", 0 }, NULL, NULL },
   { "stack-info-depth", { NULL, 0 }, 0, mi_cmd_stack_info_depth},
   { "stack-info-frame", { NULL, 0 }, 0, mi_cmd_stack_info_frame},
   { "stack-list-arguments", { NULL, 0 }, 0, mi_cmd_stack_list_args},
-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

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

[Eli Zaretskii]

> Date: Sat, 2 Jun 2007 21:34:01 +0200 (CEST)
> From: "Ulrich Weigand" <uweigand@de.ibm.com>
> Cc: eliz@gnu.org
> 
> Eli, doc changes OK?

Yes, thanks.  I have a comment:

> +Display SPU signal notification facility status.  This command is available
> +only when @value{GDBN} is debugging the Cell Broadband Engine SPU architecture.

A cross-reference to the section you added about SPU would be useful
here.  Similarly for other MI commands that are SPU-specific.

Btw, I think the addition of SPU support and the change in the qXfer
packet are worth entries in NEWS.

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

[Ulrich Weigand]

Eli Zaretskii wrote:

> A cross-reference to the section you added about SPU would be useful
> here.  Similarly for other MI commands that are SPU-specific.

Like in the following version?

> Btw, I think the addition of SPU support and the change in the qXfer
> packet are worth entries in NEWS.

OK, I'll add a NEWS entry.

Thanks for your review!

Bye,
Ulrich


diff -urNp gdb-orig/gdb/doc/gdb.texinfo gdb-head/gdb/doc/gdb.texinfo
--- gdb-orig/gdb/doc/gdb.texinfo	2007-05-31 18:54:31.000000000 +0200
+++ gdb-head/gdb/doc/gdb.texinfo	2007-06-03 15:13:36.877339110 +0200
@@ -21155,6 +21155,90 @@ fullname="/home/nickrob/myprog.c",line="
 (gdb)
 @end smallexample
 
+@subheading The @code{-spu-info-event} Command
+@findex -spu-info-event
+
+@subheading Synopsis
+
+@smallexample
+-spu-info-event
+@end smallexample
+
+Display SPU event facility status.  This command is available only
+when @value{GDBN} is debugging the Cell Broadband Engine SPU architecture
+(@pxref{SPU}).
+
+@subheading @value{GDBN} Command
+
+The corresponding @value{GDBN} command is @samp{info spu event}.
+
+@subheading The @code{-spu-info-signal} Command
+@findex -spu-info-signal
+
+@subheading Synopsis
+
+@smallexample
+-spu-info-signal
+@end smallexample
+
+Display SPU signal notification facility status.  This command is available
+only when @value{GDBN} is debugging the Cell Broadband Engine SPU architecture
+(@pxref{SPU}).
+
+@subheading @value{GDBN} Command
+
+The corresponding @value{GDBN} command is @samp{info spu signal}.
+
+@subheading The @code{-spu-info-mailbox} Command
+@findex -spu-info-mailbox
+
+@subheading Synopsis
+
+@smallexample
+-spu-info-mailbox
+@end smallexample
+
+Display SPU mailbox facility status.  This command is available only when
+@value{GDBN} is debugging the Cell Broadband Engine SPU architecture
+(@pxref{SPU}).
+
+@subheading @value{GDBN} Command
+
+The corresponding @value{GDBN} command is @samp{info spu mailbox}.
+
+@subheading The @code{-spu-info-dma} Command
+@findex -spu-info-dma
+
+@subheading Synopsis
+
+@smallexample
+-spu-info-dma
+@end smallexample
+
+Display MFC DMA status.  This command is available only when @value{GDBN}
+is debugging the Cell Broadband Engine SPU architecture (@pxref{SPU}).
+
+@subheading @value{GDBN} Command
+
+The corresponding @value{GDBN} command is @samp{info spu dma}.
+
+@subheading The @code{-spu-info-proxydma} Command
+@findex -spu-info-proxydma
+
+@subheading Synopsis
+
+@smallexample
+-spu-info-proxydma
+@end smallexample
+
+Display MFC Proxy-DMA status.  This command is available only when
+@value{GDBN} is debugging the Cell Broadband Engine SPU architecture
+(@pxref{SPU}).
+
+@subheading @value{GDBN} Command
+
+The corresponding @value{GDBN} command is @samp{info spu proxydma}.
+
 @node Annotations
 @chapter @value{GDBN} Annotations
 

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

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

[Eli Zaretskii]

> Date: Sun, 3 Jun 2007 15:29:32 +0200 (CEST)
> From: "Ulrich Weigand" <uweigand@de.ibm.com>
> Cc: gdb-patches@sourceware.org
> 
> Eli Zaretskii wrote:
> 
> > A cross-reference to the section you added about SPU would be useful
> > here.  Similarly for other MI commands that are SPU-specific.
> 
> Like in the following version?

Yes.

> > Btw, I think the addition of SPU support and the change in the qXfer
> > packet are worth entries in NEWS.
> 
> OK, I'll add a NEWS entry.

Thanks.

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

[Daniel Jacobowitz]

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

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

[Ulrich Weigand]

Daniel Jacobowitz wrote:
> 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.

It depends, some "info spu" commands return just a couple of values,
others return a table, yet others some values followed by a table.

I agree we need to document the format, at least provide examples.
Sorry for omitting that ...

> 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.

That might be a good idea in general, but in this particular case,
preparing the data requires quite a bit of effort and knowledge of
the data format.  I'm not sure I'd want to describe the effects of,
say, info_spu_dma_cmdlist in XML.  I also want to avoid having to
duplicate that processing in GDB and the IDE ...

> If we do go ahead with these new commands I suggest you add a test
> case for them.

Right, sorry about that.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

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

[Daniel Jacobowitz]

On Mon, Jun 04, 2007 at 10:13:03PM +0200, Ulrich Weigand wrote:
> That might be a good idea in general, but in this particular case,
> preparing the data requires quite a bit of effort and knowledge of
> the data format.  I'm not sure I'd want to describe the effects of,
> say, info_spu_dma_cmdlist in XML.  I also want to avoid having to
> duplicate that processing in GDB and the IDE ...

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?

I have a half-finished sketch of a register groups interface that lets
GDB present arbitrary control structures from the target as
"registers" to the front end.  There will be a generic MI command to
get groups of these things and the individual members will show up
through -var-list-children as varobjs.  But that may not be suitable.

Another option would be something like this, if the output of the MI
commands is general enough.  Excuse my MI syntax if it's completely
wrong, please.

-> -arch-info-list
<- ^done,infos=["spu dma", "spu signals"]
-> -arch-info "spu dma"
<- ^done,[whatever]

-- 
Daniel Jacobowitz
CodeSourcery

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

[Ulrich Weigand]

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",
  dma_info_stall_and_notify="0x0",
  dma_info_atomic_command_status="0x0",
  dma_cmd=
  {
    nr_rows="16",
    nr_cols="10",
    hdr=[{width="7",alignment="-1",col_name="opcode",colhdr="Opcode"},
         {width="3",alignment="-1",col_name="tag",colhdr="Tag"},
         {width="3",alignment="-1",col_name="tid",colhdr="TId"},
         {width="3",alignment="-1",col_name="rid",colhdr="RId"},
         {width="18",alignment="-1",col_name="ea",colhdr="EA"},
         {width="7",alignment="-1",col_name="lsa",colhdr="LSA"},
         {width="7",alignment="-1",col_name="size",colhdr="Size"},
         {width="7",alignment="-1",col_name="lstaddr",colhdr="LstAddr"},
         {width="7",alignment="-1",col_name="lstsize",colhdr="LstSize"},
         {width="1",alignment="-1",col_name="error_p",colhdr="E"}],
    body=[cmd={opcode="getl",tag="0",tid="0",rid="0",
               ea="0xd00000000029f000",lsa="0x00000",size="0x00000",
               lstaddr="0x00e70",lstsize="0x00008",error_p=""},
          cmd={opcode="putllc",tag="0",tid="0",rid="0",
               ea="0xd000000000250080",lsa="0x00080",size="0x00000",
               lstaddr="",lstsize="",error_p=""},
          cmd={opcode="get",tag="5",tid="0",rid="0",
               ea="0x00000000f7f90000",lsa="0x01a00",size="0x00080",
               lstaddr="",lstsize="",error_p=""},
          cmd={opcode="mfcsync",tag="0",tid="0",rid="0",ea="",
               lsa="0x00300",size="0x00880",
               lstaddr="",lstsize="",error_p=""},
          cmd={opcode="get",tag="0",tid="0",rid="0",
               ea="0xd000000000250900",lsa="0x00e00",size="0x00000",
               lstaddr="",lstsize="",error_p=""},
          cmd={opcode="0",tag="0",tid="0",rid="0",
               ea="",lsa="0x00000",size="0x00000",
               lstaddr="",lstsize="",error_p=""},
          cmd={opcode="0",tag="0",tid="0",rid="0",
               ea="",lsa="0x00000",size="0x00000",
               lstaddr="",lstsize="",error_p=""},
          cmd={opcode="0",tag="0",tid="0",rid="0",
               ea="",lsa="0x00000",size="0x00000",
               lstaddr="",lstsize="",error_p=""},
          cmd={opcode="0",tag="0",tid="0",rid="0",
               ea="",lsa="0x00000",size="0x00000",
               lstaddr="",lstsize="",error_p=""},
          cmd={opcode="0",tag="0",tid="0",rid="0",
               ea="",lsa="0x00000",size="0x00000",
               lstaddr="",lstsize="",error_p=""},
          cmd={opcode="0",tag="0",tid="0",rid="0",
               ea="",lsa="0x00000",size="0x00000",
               lstaddr="",lstsize="",error_p=""},
          cmd={opcode="0",tag="0",tid="0",rid="0",
               ea="",lsa="0x00000",size="0x00000",
               lstaddr="",lstsize="",error_p=""},
          cmd={opcode="0",tag="0",tid="0",rid="0", 
               ea="",lsa="0x00000",size="0x00000",
               lstaddr="",lstsize="",error_p=""},
          cmd={opcode="0",tag="0",tid="0",rid="0",
               ea="",lsa="0x00000",size="0x00000",
               lstaddr="",lstsize="",error_p=""},
          cmd={opcode="0",tag="0",tid="0",rid="0",
               ea="",lsa="0x00000",size="0x00000",
               lstaddr="",lstsize="",error_p=""},
          cmd={opcode="0",tag="0",tid="0",rid="0",
               ea="",lsa="0x00000",size="0x00000",
               lstaddr="",lstsize="",error_p=""}]
  }
}


This corresponds to the information shown by "info spu dma" in the CLI:

(gdb) info spu dma
Tag-Group Status  0x00000000
Tag-Group Mask    0x00000020 (no query pending)
Stall-and-Notify  0x00000000
Atomic Cmd Status 0x00000000

Opcode  Tag TId RId EA                 LSA     Size    LstAddr LstSize E
getl    0   0   0   0xd00000000029f000 0x00000 0x00000 0x00e70 0x00008
putllc  0   0   0   0xd000000000250080 0x00080 0x00000
get     5   0   0   0x00000000f7f90000 0x01a00 0x00080
mfcsync 0   0   0                      0x00300 0x00880
get     0   0   0   0xd000000000250900 0x00e00 0x00000
0       0   0   0                      0x00000 0x00000
0       0   0   0                      0x00000 0x00000
0       0   0   0                      0x00000 0x00000
0       0   0   0                      0x00000 0x00000
0       0   0   0                      0x00000 0x00000
0       0   0   0                      0x00000 0x00000
0       0   0   0                      0x00000 0x00000
0       0   0   0                      0x00000 0x00000
0       0   0   0                      0x00000 0x00000
0       0   0   0                      0x00000 0x00000
0       0   0   0                      0x00000 0x00000

The IDE parses the above MI output to display a screen that shows
this information, formatted appropriately.

> I have a half-finished sketch of a register groups interface that lets
> GDB present arbitrary control structures from the target as
> "registers" to the front end.  There will be a generic MI command to
> get groups of these things and the individual members will show up
> through -var-list-children as varobjs.  But that may not be suitable.
> 
> Another option would be something like this, if the output of the MI
> commands is general enough.  Excuse my MI syntax if it's completely
> wrong, please.
> 
> -> -arch-info-list
> <- ^done,infos=["spu dma", "spu signals"]
> -> -arch-info "spu dma"
> <- ^done,[whatever]

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.

I'll get in touch with our IDE group and find out if they feel a
"generic" info display facility would be feasible / useful ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

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

[Daniel Jacobowitz]

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.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Ulrich Weigand]

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

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

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

[Ricardo Marin Matinata]

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 

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

[Nick Roberts]

 > So, roughly, a spu-info-dma would be transformed in to something like
 > this:
 >
 > -arch-info dma
 > ^done
 > (gdb) 

I'm out of my depth but isn't all this really target information, i.e., I
could be on an i386 debugging spu remotely?

It's for you to decide if you want to display the information as for variable
objects or not but presumably there might be other architectures that
want provide similar output, e.g, "info mytarget dma".  So I think a further
command is needed:

(gdb)
-target-name
^done,value="spu"
(gdb)
-target-info-list
^done,infos=[name="event",name="signal","name=mailbox",name="dma",name="proxydma"]

 > -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",
 >...


-- 
Nick                                           http://www.inet.net.nz/~nickrob

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

[Jim Blandy]

If I understand right, many components of Eclipse are moving towards
using the "Versatile Hierarchy" facility, which seems to be a general
mechanism for displaying structured information.  I don't understand
the details very well, but would it be useful to have an XML- or
MI-like form for describing hierarchies that Eclipse could just
display without understanding the details much?  GDB could stay
ignorant of the details; it would simply pass through XML received
directly from the target.

That XML could be annotated to connect it with things GDB does know
about, like SPEs, threads, and the like.