From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: drow@false.org (Daniel Jacobowitz), rmm@br.ibm.com
Cc: gdb-patches@sourceware.org, eliz@gnu.org
Subject: Re: [rfc/rfa] [4/4] SPU enhancements: GDB/MI extensions
Date: Thu, 14 Jun 2007 20:05:00 -0000 [thread overview]
Message-ID: <200706142004.l5EK4vTO021141@d12av02.megacenter.de.ibm.com> (raw)
In-Reply-To: <20070605111134.GA3993@caradoc.them.org> from "Daniel Jacobowitz" at Jun 05, 2007 07:11:34 AM
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
next prev parent reply other threads:[~2007-06-14 20:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-02 19:34 Ulrich Weigand
2007-06-02 20:38 ` Eli Zaretskii
2007-06-03 13:29 ` Ulrich Weigand
2007-06-03 16:45 ` Eli Zaretskii
2007-06-04 20:00 ` Daniel Jacobowitz
2007-06-04 20:13 ` Ulrich Weigand
2007-06-04 20:22 ` Daniel Jacobowitz
2007-06-04 22:59 ` Ulrich Weigand
2007-06-05 11:12 ` Daniel Jacobowitz
2007-06-14 20:05 ` Ulrich Weigand [this message]
2007-06-21 2:23 ` Ricardo Marin Matinata
2007-06-21 22:22 ` Nick Roberts
2007-06-22 20:53 ` Jim Blandy
2007-06-20 0:28 Nick Roberts
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200706142004.l5EK4vTO021141@d12av02.megacenter.de.ibm.com \
--to=uweigand@de.ibm.com \
--cc=drow@false.org \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=rmm@br.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox