Re: GDB/XMI (XML Machine Interface)

Re: GDB/XMI (XML Machine Interface)

[Felix Lee]

Felix Lee <felix.1@canids.net>:
> Bob Rossi <bob@brasko.net>:
> >    1. Have to write a parser. (regex, recursive decent)
> >       BTW, I guarantee the parser will have to be updated with every
> >       release of GDB.
> so far, I haven't found that xml is any less work than that, and
> it usually feels like a lot more work, but I haven't used xml for
> anything substantial yet, so it may just be unfamiliarity.

here's some elaboration.  this is what I think about xml parsers
today.  please correct me if I'm wrong.

there are two types of xml parsers, stream-based and tree-based.

using an xml stream parser is equivalent to writing a recursive
descent parser.  the stream parser basically just handles the
'tokenization' aspect of parsing xml (which is complicated by
considerations like character encoding, etc.)

to read data with an xml stream parser, you have to write
handlers that match the structure of the data you're parsing,
which is not any simpler than writing a recursive descent parser
for some other tree-like data format.

using an xml tree parser is complicated by xml's origin as a
markup language, which introduces issues that aren't particularly
relevant to data representation, but can't easily be ignored.

something like perl's XML::Simple tries to hide the messy details
and give you a natural data structure that corresponds to an xml
document, but there are a few problems that make XML::Simple
unsuitable for data that isn't "simple".

using a more general xml tree parser is harder.  in order to
access the data you want, you either have to walk the document
tree yourself (which is similar to writing a recursive descent
parser) or use XPATH descriptions to locate items in the tree
(which is similar to using regexps).

xml tree parsers also have the disadvantage of needing a lot of
memory.  the estimates are 10x to 30x the size of the xml
document, which puzzles me.  it's not clear to me why you'd need
more than about 2x.  (actually I'd expect more like 0.8x since
xml is redundantly verbose.)

with either stream parsers or tree parsers, if an xml schema
changes, you have to revise your code, unless the change is
careful to make only backward-compatible extensions.
guaranteeing that is hard for nontrivial changes, so people often
screw it up, or they play it safe and define a new schema.  in
either case, old code will often require updating anyway.
--

Re: GDB/XMI (XML Machine Interface)

[Bob Rossi]

On Sat, Aug 21, 2004 at 07:55:27PM -0700, Felix Lee wrote:
> Felix Lee <felix.1@canids.net>:
> > Bob Rossi <bob@brasko.net>:
> > >    1. Have to write a parser. (regex, recursive decent)
> > >       BTW, I guarantee the parser will have to be updated with every
> > >       release of GDB.
> > so far, I haven't found that xml is any less work than that, and
> > it usually feels like a lot more work, but I haven't used xml for
> > anything substantial yet, so it may just be unfamiliarity.
> 
> here's some elaboration.  this is what I think about xml parsers
> today.  please correct me if I'm wrong.
> 
> there are two types of xml parsers, stream-based and tree-based.
> 
> using an xml stream parser is equivalent to writing a recursive
> descent parser.  the stream parser basically just handles the
> 'tokenization' aspect of parsing xml (which is complicated by
> considerations like character encoding, etc.)

This is obtuse. Using the tree representation of an XML parser is
equivalent to using the tree representation of a recursive descent
parser. 

   You do not have to write the lexer, parser, tree representation or
   lookup functions ( XPATH ) if you use XML.

   You have to write the lexer ( flex ), parser ( bison ), tree
   representation format, lookup features if you use a recursive descent
   parser.

BTW, I am writing a recursive descent parser because everyone here seems
to hate XML. Does anyone have the bison rules already written out
(sharign would be *greatly* appreciated)? Or am I the first one?

Thanks,
Bob Rossi

Re: GDB/XMI (XML Machine Interface)

[Fabian Cenedese]

>xml tree parsers also have the disadvantage of needing a lot of
>memory.  the estimates are 10x to 30x the size of the xml
>document, which puzzles me.  it's not clear to me why you'd need
>more than about 2x.  (actually I'd expect more like 0.8x since
>xml is redundantly verbose.)

I guess part of it is because you need additional managing data.
Tree nodes, list nodes, pointers, counters, whatever... In the
XML file the same structure is just laid out by order of the lines.

bye  Fabi

Re: GDB/XMI (XML Machine Interface)

[Felix Lee]

Bob Rossi <bob@brasko.net>:
> I would think it not very nice of the GDB team to set me loose
> on this patch, and then outright reject it. Where is the open source
> camaraderie?

I don't think any open source project can promise to accept a
patch before seeing it.  if you don't want to put effort into
that risk, then how about putting effort into a separate xmlgdb
wrapper.  if enough people use it, then it's easy to argue for
inclusion in the source tree, and perhaps making it an interp
module rather than a wrapper.

don't let the discussion discourage you if you're sure xml is the
right approach.  you can trump many arguments with working code
and a user base.
--

Re: GDB/XMI (XML Machine Interface)

[Felix Lee]

Bob Rossi <bob@brasko.net>:
>    1. Have to write a parser. (regex, recursive decent)
>       BTW, I guarantee the parser will have to be updated with every
>       release of GDB.

so far, I haven't found that xml is any less work than that, and
it usually feels like a lot more work, but I haven't used xml for
anything substantial yet, so it may just be unfamiliarity.
--

Re: GDB/XMI (XML Machine Interface)

[Bob Rossi]

On Sat, Aug 21, 2004 at 12:21:44PM -0700, Felix Lee wrote:
> Bob Rossi <bob@brasko.net>:
> > I believe  that making GDB output XML would almost make it
> > scriptable. Someone writing in perl or java could quickly conjure up
> > some commands and parse the output of GDB in a matter of minutes.
> 
> what about MI makes you feel like gdb isn't scriptable now?  MI
> seems pretty easy to pull apart with regexps.

That is ridiculous. Let me make something clear. In order to integrate
GDB with, say perl, you would either 

   1. Have to write a parser. (regex, recursive decent)
      BTW, I guarantee the parser will have to be updated with every
      release of GDB.
   2. Do nothing but use the information given to you.
      BTW, you will never ever have to worry about what GDB outputs,
      because it is irrelevant. You get the info you want, and you use
      it.

Bob Rossi

Re: GDB/XMI (XML Machine Interface)

[Bob Rossi]

On Sat, Aug 21, 2004 at 12:28:11PM -0700, Felix Lee wrote:
> Bob Rossi <bob@brasko.net>:
> > I believe that making GDB output XML would be trivial.
> 
> ok, so submit a patch to implement --interpreter=xml.
> --

Well of course I was going to implement a patch, or at least try. The
point is to get some sort of consensus as to if the patch would be
approved. I would think it not very nice of the GDB team to set me loose
on this patch, and then outright reject it. Where is the open source
camaraderie?

Thanks,
Bob Rossi

Re: GDB/XMI (XML Machine Interface)

[Felix Lee]

Bob Rossi <bob@brasko.net>:
> I believe that making GDB output XML would be trivial.

ok, so submit a patch to implement --interpreter=xml.
--

Re: GDB/XMI (XML Machine Interface)

[Felix Lee]

Bob Rossi <bob@brasko.net>:
> I believe  that making GDB output XML would almost make it
> scriptable. Someone writing in perl or java could quickly conjure up
> some commands and parse the output of GDB in a matter of minutes.

what about MI makes you feel like gdb isn't scriptable now?  MI
seems pretty easy to pull apart with regexps.

anyway, a wrapper that translates gdb's interface to xml would
also let anyone do what you want.
--

Re: GDB/XMI (XML Machine Interface)

[Eli Zaretskii]

> Date: Sat, 21 Aug 2004 08:34:40 -0400
> From: Bob Rossi <bob@brasko.net>
> 
> These designated individuals either are busy or refuse to even discuss
> the topic at hand.

I was talking about code submitted for inclusion, not about ideas.

> > I'm neither Andrew nor Elena nor Fernando, but I will try to summarize
> > the impression I got from this discussion so far: your proposal
> > mentioned several problems with MI, but most of those problems can
> > (and IMHO should) be solved without ditching MI, and the effort to
> > solve those problems with XMI is not going to be smaller.  One notable
> > example of such problems is back compatibility, but there were others.
> 
> I believe that making GDB output XML would be trivial.

I don't think so, but that was not what I meant to say in the portion
you cited.

I meant to say that to overcome most of the problems you mentioned
(saying that they originate from MI usage), it will not be enough just
to teach GDB speak XML.  Overcoming those problems will need
additional effort, regardless of whether GDB speaks XML or not.
Others explained in detail why is that so, but if you want to discuss
it again, let's take the back compatibility issue and analyze it.

> > I agree that it would be a Good Thing if GDB would come with a
> > read-to-use MI parser library.  If you care about easing the pains of
> > a GDB front-end programmer, then the project of writing such a parsing
> > library should sound important to you.  But since you said quite
> > explicitly that you are not interested in such a project, 
> 
> I am going to have to write an MI parser, if GDB refuses to simplfy it's
> output.

Then how about doing what I believe was proposed in this thread: write
an MI parsing library that every front-end programmer could use
henceforth?  I thought you said that you were not interested in doing
that, but I cannot understand why, given the fact that you will be the
very first user of such a library.

> I care nothing about XML. As I say it over and over again. If XML is
> outputted by GDB, it could be binary for all I care, NO parser has to be
> written. The job has already been done.
> 
>    I would not have to write a parser.
>    I would not have to write a library.
>    No one would.
>    Ever.

That might be true, but then we will need to solve the problem of
changes in the XMI in some way, be it via DTD or otherwise.  Producing
a DTD and maintaining it in sync with the modifications in XMI is a
maintenance burden we currently don't have.

Also, the effort to teach GDB speak XML is a non-trivial effort, and
maintaining that together with MI and annotations (as we cannot simply
drop existing interfaces overnight) is in itself a burden.

So, more generally, one can say that switching to XML does not
miraculously remove the need to invest some effort when we change the
output syntax.  Therefore, we need to weight the advantages and
disadvantages of your proposal, which is what this discussion was all
about, I believe.  So it's not that people here are somehow prejudiced
against XML, they simply think that the benefits from going XML are
not significant enough, while most of the problems that exist with MI
will not be solved by switching to XML.

Re: GDB/XMI (XML Machine Interface)

[Bob Rossi]

On Fri, Aug 20, 2004 at 12:19:58PM -0700, Felix Lee wrote:
> Daniel Jacobowitz <drow@false.org>:
> > Oh, come on.  That's why I suggested writing a library that parses the
> > MI and outputs XML.  You run that as a wrapper around GDB; that's real
> > easy.
> 
> oh, right.  ok, that works for me.
> --

I think there are other benefits of working with XML. Basically, people
that want to use GDB for a small part of there project, could quickly
write some code to get GDB to give a backtrace, or perform some other
activity. I believe  that making GDB output XML would almost make it
scriptable. Someone writing in perl or java could quickly conjure up
some commands and parse the output of GDB in a matter of minutes.

This will never happen with MI.

Thanks,
Bob Rossi

Re: GDB/XMI (XML Machine Interface)

[Bob Rossi]

On Sat, Aug 21, 2004 at 01:20:33PM +0300, Eli Zaretskii wrote:
> > Date: Fri, 20 Aug 2004 15:59:28 -0400
> > From: Bob Rossi <bob@brasko.net>
> > 
> > Changing the MI output to XML would greatly reduce the amount of time
> > and code written to interface with GDB. Period. I strongly believe there
> > is no argument against this point.
> 
> Strangely enough, none of the maintainers of the GDB front ends were
> enthusiastic about your proposal.  Perhaps that's because they already
> have their MI parser written, so the issue of reducing the effort of
> writing one does not bother them.

Right, this is understandably so. I would also not be interested if I
had already written my mi1 and mi2 parser. However, that doesn't mean
it's not the correct decision. Instead of writing a new parser, they
will get one for free, that they will never have to maintain. Doesn't
that sound nice?

> > BTW, how does one go about getting a yes/no answer to such an RFC? Do I
> > need the approval of the majority of GDB contributors? maintainers?
> 
> If you are looking for approval before you write the code, you've just
> heard the relevant opinions.  I believe this is all you can hope for.
> Whether that is enough for you to sit down and start writing is
> something you should decide on your own.
> 
> The way to get something into GDB is to write code and then submit it
> for approval.  Then there are designated individuals (mentioned in
> MAINTAINERS) who should review the code and either approve it or point
> out the parts that should be rewritten or corrected.

These designated individuals either are busy or refuse to even discuss
the topic at hand. This is awfully unfriendly.

> > Also, why haven't some of the maintainers of MI responded at all on this
> > subject? Andrew or Elena? Fernando are you the main contact as far as
> > decisions on the MI code goes?
> 
> I'm neither Andrew nor Elena nor Fernando, but I will try to summarize
> the impression I got from this discussion so far: your proposal
> mentioned several problems with MI, but most of those problems can
> (and IMHO should) be solved without ditching MI, and the effort to
> solve those problems with XMI is not going to be smaller.  One notable
> example of such problems is back compatibility, but there were others.

I believe that making GDB output XML would be trivial.

> I agree that it would be a Good Thing if GDB would come with a
> read-to-use MI parser library.  If you care about easing the pains of
> a GDB front-end programmer, then the project of writing such a parsing
> library should sound important to you.  But since you said quite
> explicitly that you are not interested in such a project, 

I am going to have to write an MI parser, if GDB refuses to simplfy it's
output. I have already been working on a project TGDB, and anyone that
wants to use it to base there front ends on GDB is welcome.

> I suspect
> that your interest is in playing with XML rather than easing the lives
> of front-end programmers out there.  There's nothing wrong with your
> interest in XML, of course, but you must understand that the interests
> of GDB maintainers are elsewhere, and rightly so.

I care nothing about XML. As I say it over and over again. If XML is
outputted by GDB, it could be binary for all I care, NO parser has to be
written. The job has already been done.

   I would not have to write a parser.
   I would not have to write a library.
   No one would.
   Ever.

This is my point. I think that might have been my very first epilogue :)

BTW, if none of the front end writers or maintainers like this idea, I
will silently drop the issue. Personally, I thought  many of the front
end writers would appreciate such a transparent protocol.

Thanks,
Bob Rossi

Re: GDB/XMI (XML Machine Interface)

[Eli Zaretskii]

> Date: Fri, 20 Aug 2004 15:59:28 -0400
> From: Bob Rossi <bob@brasko.net>
> 
> Changing the MI output to XML would greatly reduce the amount of time
> and code written to interface with GDB. Period. I strongly believe there
> is no argument against this point.

Strangely enough, none of the maintainers of the GDB front ends were
enthusiastic about your proposal.  Perhaps that's because they already
have their MI parser written, so the issue of reducing the effort of
writing one does not bother them.

> BTW, how does one go about getting a yes/no answer to such an RFC? Do I
> need the approval of the majority of GDB contributors? maintainers?

If you are looking for approval before you write the code, you've just
heard the relevant opinions.  I believe this is all you can hope for.
Whether that is enough for you to sit down and start writing is
something you should decide on your own.

The way to get something into GDB is to write code and then submit it
for approval.  Then there are designated individuals (mentioned in
MAINTAINERS) who should review the code and either approve it or point
out the parts that should be rewritten or corrected.

> Also, why haven't some of the maintainers of MI responded at all on this
> subject? Andrew or Elena? Fernando are you the main contact as far as
> decisions on the MI code goes?

I'm neither Andrew nor Elena nor Fernando, but I will try to summarize
the impression I got from this discussion so far: your proposal
mentioned several problems with MI, but most of those problems can
(and IMHO should) be solved without ditching MI, and the effort to
solve those problems with XMI is not going to be smaller.  One notable
example of such problems is back compatibility, but there were others.

So, by and large, your proposal seems to be not a silver bullet, but
rather an additional burden on the GDB maintenance, i.e. yet another
interface language and interpreter that can easily run the same risk
of bit rotting as the other interfaces.

I agree that it would be a Good Thing if GDB would come with a
read-to-use MI parser library.  If you care about easing the pains of
a GDB front-end programmer, then the project of writing such a parsing
library should sound important to you.  But since you said quite
explicitly that you are not interested in such a project, I suspect
that your interest is in playing with XML rather than easing the lives
of front-end programmers out there.  There's nothing wrong with your
interest in XML, of course, but you must understand that the interests
of GDB maintainers are elsewhere, and rightly so.

Re: GDB/XMI (XML Machine Interface)

[Felix Lee]

Bob Rossi <bob@brasko.net>:
> I am not interested in writing this library. I am interested in the XML
> approach. Do you know why yet? It's because I won't have to write a
> library. No one will. Ever.

parsing mi is trivial.  writing a wrapper to do bidirectional
translation to xml is trivial.  designing the schema is the hard
part.  all this can be done without changes to gdb itself.  if
it's workable and maintainable, then it will be easier to
convince people to absorb it into the gdb source and remove the
indirection so that gdb speaks xml 'natively'.
--

Re: GDB/XMI (XML Machine Interface)

[Bob Rossi]

On Fri, Aug 20, 2004 at 03:42:24PM -0400, Daniel Jacobowitz wrote:
> On Fri, Aug 20, 2004 at 03:24:58PM -0400, Bob Rossi wrote:
> > > > > Heck, parse it into XML if you'd like.
> > > > 
> > > > I don't want the data to be in XML. I just want the data without writing
> > > > a parser. and a protocol that is backwards compatible. This seems like a
> > > > simple think to ask for.
> > > > 
> > > > If GDB expects to have one common MI library, than it should distribute
> > > > a library that is responsible for reading it's own output, and giving
> > > > the user some data structures that will be backwards compatible. Thus, a
> > > > library to link against.
> > > 
> > > So, it would be a waste of your time to write a parser that all future
> > > front ends could use, but not a waste of GDB developers' time to carry
> > > out major incompatible surgery on GDB's output format for people that
> > > already parse MI?
> > 
> > What? I am saying that if GDB wants to stick with this self invented
> > grammer and decides that it is obviously silly to have all of the
> > consumers reinventing the wheel, it should write a library that parses
> > the MI output and give it to the user in some sort of ADT. Making the
> > protocol transparent. If this existed, I would be satisfied.
> > 
> > I wouldn't expect anyone but myself and people that believed in the idea
> > to carry out the surgery. I am not asking for a present.
> 
> That's what I was suggesting you do - write that library.

I am not interested in writing this library. I am interested in the XML
approach. Do you know why yet? It's because I won't have to write a
library. No one will. Ever.

> > I feel that an XML approach will save developers time over the long run
> > and that inventing a grammer to parse on output was a mistake in the
> > first place. 
> > 
> > Is the *main* argument to stick with MI because there is already a
> > customer base?
> 
> There's no "main" argument, but there seem to be lots of existing
> arguments.  Myself, I don't have much reason to care, but I agree with
> Chris that typiing XML by hand is a real pain, but MI is manageable
> (and I do it periodically).
> 
> I don't think that using XML would change anything.  Several people
> have already presented my opinion better than I could.

You are missing the point. It would change the amount of work a front
end writer had to do to implement to GDB.  XML is clearly a better
approach to communicating data between 2 entities. It is a proven
technique that has parsers written in many languages.

Changing the MI output to XML would greatly reduce the amount of time
and code written to interface with GDB. Period. I strongly believe there
is no argument against this point.

Other reasons for not wanting to switch to XML seem relavant, such as,
typeing XML commands to talk to GDB. However, I have two arguments to
that. 
   If you were to send XML commands to GDB, most of the time they would
   be short.
   <next/>

   Second, the commands sent to GDB don't have to be XML, although I
   think that they should be.

BTW, how does one go about getting a yes/no answer to such an RFC? Do I
need the approval of the majority of GDB contributors? maintainers?

Also, why haven't some of the maintainers of MI responded at all on this
subject? Andrew or Elena? Fernando are you the main contact as far as
decisions on the MI code goes?

Thanks,
Bob Rossi

Re: GDB/XMI (XML Machine Interface)

[Daniel Jacobowitz]

On Fri, Aug 20, 2004 at 03:24:58PM -0400, Bob Rossi wrote:
> > > > Heck, parse it into XML if you'd like.
> > > 
> > > I don't want the data to be in XML. I just want the data without writing
> > > a parser. and a protocol that is backwards compatible. This seems like a
> > > simple think to ask for.
> > > 
> > > If GDB expects to have one common MI library, than it should distribute
> > > a library that is responsible for reading it's own output, and giving
> > > the user some data structures that will be backwards compatible. Thus, a
> > > library to link against.
> > 
> > So, it would be a waste of your time to write a parser that all future
> > front ends could use, but not a waste of GDB developers' time to carry
> > out major incompatible surgery on GDB's output format for people that
> > already parse MI?
> 
> What? I am saying that if GDB wants to stick with this self invented
> grammer and decides that it is obviously silly to have all of the
> consumers reinventing the wheel, it should write a library that parses
> the MI output and give it to the user in some sort of ADT. Making the
> protocol transparent. If this existed, I would be satisfied.
> 
> I wouldn't expect anyone but myself and people that believed in the idea
> to carry out the surgery. I am not asking for a present.

That's what I was suggesting you do - write that library.

> I feel that an XML approach will save developers time over the long run
> and that inventing a grammer to parse on output was a mistake in the
> first place. 
> 
> Is the *main* argument to stick with MI because there is already a
> customer base?

There's no "main" argument, but there seem to be lots of existing
arguments.  Myself, I don't have much reason to care, but I agree with
Chris that typiing XML by hand is a real pain, but MI is manageable
(and I do it periodically).

I don't think that using XML would change anything.  Several people
have already presented my opinion better than I could.

-- 
Daniel Jacobowitz

Re: GDB/XMI (XML Machine Interface)

[Bob Rossi]

> > > Heck, parse it into XML if you'd like.
> > 
> > I don't want the data to be in XML. I just want the data without writing
> > a parser. and a protocol that is backwards compatible. This seems like a
> > simple think to ask for.
> > 
> > If GDB expects to have one common MI library, than it should distribute
> > a library that is responsible for reading it's own output, and giving
> > the user some data structures that will be backwards compatible. Thus, a
> > library to link against.
> 
> So, it would be a waste of your time to write a parser that all future
> front ends could use, but not a waste of GDB developers' time to carry
> out major incompatible surgery on GDB's output format for people that
> already parse MI?

What? I am saying that if GDB wants to stick with this self invented
grammer and decides that it is obviously silly to have all of the
consumers reinventing the wheel, it should write a library that parses
the MI output and give it to the user in some sort of ADT. Making the
protocol transparent. If this existed, I would be satisfied.

I wouldn't expect anyone but myself and people that believed in the idea
to carry out the surgery. I am not asking for a present.

I feel that an XML approach will save developers time over the long run
and that inventing a grammer to parse on output was a mistake in the
first place. 

Is the *main* argument to stick with MI because there is already a
customer base?

Bob Rossi

Re: GDB/XMI (XML Machine Interface)

[Felix Lee]

Daniel Jacobowitz <drow@false.org>:
> Oh, come on.  That's why I suggested writing a library that parses the
> MI and outputs XML.  You run that as a wrapper around GDB; that's real
> easy.

oh, right.  ok, that works for me.
--

Re: GDB/XMI (XML Machine Interface)

[Daniel Jacobowitz]

On Fri, Aug 20, 2004 at 12:06:22PM -0700, Felix Lee wrote:
> Daniel Jacobowitz <drow@false.org>:
> > Parsing MI over and over again from scratch may be a waste of time.  So
> > write once a library that parses MI.  Then you gain most of the benefit
> > of having XML parsing libraries available.
> 
> xml has the advantage of being language neutral.  a library in C
> or whatever takes more work to use in other languages.

Oh, come on.  That's why I suggested writing a library that parses the
MI and outputs XML.  You run that as a wrapper around GDB; that's real
easy.

-- 
Daniel Jacobowitz

Re: GDB/XMI (XML Machine Interface)

[Felix Lee]

Daniel Jacobowitz <drow@false.org>:
> Parsing MI over and over again from scratch may be a waste of time.  So
> write once a library that parses MI.  Then you gain most of the benefit
> of having XML parsing libraries available.

xml has the advantage of being language neutral.  a library in C
or whatever takes more work to use in other languages.
--

Re: GDB/XMI (XML Machine Interface)

[Daniel Jacobowitz]

On Fri, Aug 20, 2004 at 02:49:00PM -0400, Bob Rossi wrote:
> On Fri, Aug 20, 2004 at 02:34:48PM -0400, Daniel Jacobowitz wrote:
> > On Fri, Aug 20, 2004 at 08:54:43AM -0400, Bob Rossi wrote:
> > > On Fri, Aug 20, 2004 at 03:34:19AM -0700, Felix Lee wrote:
> > > > this isn't a strong objection, interoperability takes precedence.
> > > > I think an argument for xml would be more convincing if there
> > > > were more than one debugger talking the same protocol.  
> > > 
> > > I can see that people are interested in writing front ends that parse the
> > > output of the MI. Why? Do the same people enjoy writing linked lists
> > > over and over again? Do you see my point? Parsing the output of MI is
> > > completely a waste of time. 
> > 
> > Parsing MI over and over again from scratch may be a waste of time.  So
> > write once a library that parses MI.  Then you gain most of the benefit
> > of having XML parsing libraries available.
> 
> Why would I write it once? That would be a waste of my time. 

So that all front ends could use it.

> > Heck, parse it into XML if you'd like.
> 
> I don't want the data to be in XML. I just want the data without writing
> a parser. and a protocol that is backwards compatible. This seems like a
> simple think to ask for.
> 
> If GDB expects to have one common MI library, than it should distribute
> a library that is responsible for reading it's own output, and giving
> the user some data structures that will be backwards compatible. Thus, a
> library to link against.

So, it would be a waste of your time to write a parser that all future
front ends could use, but not a waste of GDB developers' time to carry
out major incompatible surgery on GDB's output format for people that
already parse MI?

-- 
Daniel Jacobowitz

Re: GDB/XMI (XML Machine Interface)

[Bob Rossi]

On Fri, Aug 20, 2004 at 02:34:48PM -0400, Daniel Jacobowitz wrote:
> On Fri, Aug 20, 2004 at 08:54:43AM -0400, Bob Rossi wrote:
> > On Fri, Aug 20, 2004 at 03:34:19AM -0700, Felix Lee wrote:
> > > this isn't a strong objection, interoperability takes precedence.
> > > I think an argument for xml would be more convincing if there
> > > were more than one debugger talking the same protocol.  
> > 
> > I can see that people are interested in writing front ends that parse the
> > output of the MI. Why? Do the same people enjoy writing linked lists
> > over and over again? Do you see my point? Parsing the output of MI is
> > completely a waste of time. 
> 
> Parsing MI over and over again from scratch may be a waste of time.  So
> write once a library that parses MI.  Then you gain most of the benefit
> of having XML parsing libraries available.

Why would I write it once? That would be a waste of my time. 

> Heck, parse it into XML if you'd like.

I don't want the data to be in XML. I just want the data without writing
a parser. and a protocol that is backwards compatible. This seems like a
simple think to ask for.

If GDB expects to have one common MI library, than it should distribute
a library that is responsible for reading it's own output, and giving
the user some data structures that will be backwards compatible. Thus, a
library to link against.

Bob Rossi 

Re: GDB/XMI (XML Machine Interface)

[Daniel Jacobowitz]

On Fri, Aug 20, 2004 at 08:54:43AM -0400, Bob Rossi wrote:
> On Fri, Aug 20, 2004 at 03:34:19AM -0700, Felix Lee wrote:
> > this isn't a strong objection, interoperability takes precedence.
> > I think an argument for xml would be more convincing if there
> > were more than one debugger talking the same protocol.  
> 
> I can see that people are interested in writing front ends that parse the
> output of the MI. Why? Do the same people enjoy writing linked lists
> over and over again? Do you see my point? Parsing the output of MI is
> completely a waste of time. 

Parsing MI over and over again from scratch may be a waste of time.  So
write once a library that parses MI.  Then you gain most of the benefit
of having XML parsing libraries available.

Heck, parse it into XML if you'd like.

-- 
Daniel Jacobowitz

Re: GDB/XMI (XML Machine Interface)

[Felix Lee]

Bob Rossi <bob@brasko.net>:
> I think the main point behind XML is that it is human readable. Also,
> every XML developer knows how to read it. Meaning that, I believe it
> would take less time to learn how to read it, than some open source
> project's grammar. BTW, you don't even have to learn how to read it,
> because you don't have to parse it :) The only thing you need to know,
> is the spec.

xml always reminds me of a less-readable form of COBOL.  I have a
hard time spotting errors like 'wrong value' in xml, because it's
filled with a lot of visual noise that doesn't particularly help
humans or machines read it (similar to what Edward Tufte calls
'chartjunk').

> I can see that people are interested in writing front ends that parse the
> output of the MI. Why? Do the same people enjoy writing linked lists
> over and over again? Do you see my point? Parsing the output of MI is
> completely a waste of time. 

I don't know about anyone else.  it's not that I particularly
enjoy writing parsers, but xml triggers my 'big and bloaty'
reflex.  when efficiency isn't important, I tend to favor lisp
syntax, which to me is a lot more readable than xml.  and I feel
like 'include a lisp interpreter' is less code complexity and
less resource requirements than 'use a validating xml parser',
but I haven't done formal measurements of that.

(yaml might be a reasonable alternative for people who dislike
lisp and xml.)

basically, xml annoys me on an aesthetic level, and it seems to
me it's based on unsound philosophical assumptions, but since the
whole computer world seems intent on using it... *shrug* it
mostly makes me want to leave the computer industry, much like
the dominance of Windows.  but of course, this isn't relevant to
anyone else.

if someone with time and motivation wants to implement and
maintain an xml schema for debugger gui<->backend interaction,
that's probably a good thing.
--

Re: GDB/XMI (XML Machine Interface)

[Bob Rossi]

On Fri, Aug 20, 2004 at 03:34:19AM -0700, Felix Lee wrote:
> Chris Friesen <gdb001@speakeasy.net>:
> >     Didn't see a big benefit in using one structured data format over 
> > the other. All things being equal, finds pages of MI easier to read 
> > than the order of magnitude longer output that XML would be.
> 
> yeah, that's my main issue with xml, it's not very human
> readable, and it doesn't seem particularly easy to machine
> process either, but the canned libraries hide most of that.

I think the main point behind XML is that it is human readable. Also,
every XML developer knows how to read it. Meaning that, I believe it
would take less time to learn how to read it, than some open source
project's grammar. BTW, you don't even have to learn how to read it,
because you don't have to parse it :) The only thing you need to know,
is the spec.

> this isn't a strong objection, interoperability takes precedence.
> I think an argument for xml would be more convincing if there
> were more than one debugger talking the same protocol.  

I can see that people are interested in writing front ends that parse the
output of the MI. Why? Do the same people enjoy writing linked lists
over and over again? Do you see my point? Parsing the output of MI is
completely a waste of time. 

> if the
> schema is sensible, it shouldn't be too hard to make the python
> debugger and the perl debugger and so forth speak the same xml.
> --

This is a great point.

Bob Rossi

Re: GDB/XMI (XML Machine Interface)

[Bob Rossi]

On Fri, Aug 20, 2004 at 12:09:25AM -0700, Chris Friesen wrote:
> 
> On Aug 19, 2004, at 4:49 PM, Bob Rossi wrote:
> <whack>
> >
> >Chris F suggested,
> >   He defiantly didn't see the benefit to switching to XMI, since XML 
> >is harder
> >   for him to understand than MI output.
> 
> That's uncharitable, try:
>    Didn't see a big benefit in using one structured data format over 
> the other. All things being equal, finds pages of MI easier to read 
> than the order of magnitude longer output that XML would be.

I'm sorry, I worded that bad, didn't I? I did not mean "understand" as
in comprehend, anyways, thanks for correcting me.

> >I don't really know where to go from here. The XML change I think is a 
> >no brainer.
> <snip>
> >
> >Finally, the difference between a text based protocol and a libgdb 
> >interface is irrelevant
> >to me. I would personally prefer the text based protocol at this point 
> >in time seeing that
> >there is no libgdb. What stopped the production of that effort?
> 
> Did license issues prevent adoption? I know that would likely keep me 
> from being able to use a libgdb. Yeah, yeah dry your eyes. ;-)

Good point.

Bob Rossi

Re: GDB/XMI (XML Machine Interface)

[Felix Lee]

Chris Friesen <gdb001@speakeasy.net>:
>     Didn't see a big benefit in using one structured data format over 
> the other. All things being equal, finds pages of MI easier to read 
> than the order of magnitude longer output that XML would be.

yeah, that's my main issue with xml, it's not very human
readable, and it doesn't seem particularly easy to machine
process either, but the canned libraries hide most of that.

this isn't a strong objection, interoperability takes precedence.
I think an argument for xml would be more convincing if there
were more than one debugger talking the same protocol.  if the
schema is sensible, it shouldn't be too hard to make the python
debugger and the perl debugger and so forth speak the same xml.
--

Re: GDB/XMI (XML Machine Interface)

[Chris Friesen]

On Aug 19, 2004, at 4:49 PM, Bob Rossi wrote:
<whack>
>
> Chris F suggested,
>    He defiantly didn't see the benefit to switching to XMI, since XML 
> is harder
>    for him to understand than MI output.

That's uncharitable, try:
    Didn't see a big benefit in using one structured data format over 
the other. All things being equal, finds pages of MI easier to read 
than the order of magnitude longer output that XML would be.

> I don't really know where to go from here. The XML change I think is a 
> no brainer.
<snip>
>
> Finally, the difference between a text based protocol and a libgdb 
> interface is irrelevant
> to me. I would personally prefer the text based protocol at this point 
> in time seeing that
> there is no libgdb. What stopped the production of that effort?

Did license issues prevent adoption? I know that would likely keep me 
from being able to use a libgdb. Yeah, yeah dry your eyes. ;-)

Go for the Gold,
-ChrisF

Re: GDB/XMI (XML Machine Interface)

[Bob Rossi]

On Tue, Aug 10, 2004 at 04:14:40PM -0400, Bob Rossi wrote:
> Hi,
> 
> As most of you know, I have been writing a front end to GDB called CGDB.
> However, for a while now, I have been a little disappointed with the MI
> interface. In my RFC I have described the problems I have with MI and I
> have proposed a new method of communication between GDB and the front
> end.
> 
> If there is good feedback on this RFC, I will continue research on it,
> filling in details that I thought would be best to wait until after an
> initial acceptance.
> 
> If the RFC is accepted by the community I plan on implementing an
> initial version of the XMI interface in GDB, and programming CGDB to 
> sit on top of GDB. This will at least give the community one open 
> source front end to GDB and an example to prove that the new 
> machine interface works.
> 
> I can't wait to hear your opinions/comments.

Hi,

Well, it seems as if my efforts only brought up enough interest to just 
get a couple of replies. 

Basically, most of you point out that I am interested in changing at a high 
level the development process of the interface between GDB and the front end.
Obviously, switching GDB's output to XML only gains the front ends a simple
way to parse the data. Besides validation, and maybe transformations, it 
basically does nothing else. I have listed some other higher level things, like 
Michael pointed out. These are the things that I feel will make my front end 
successful over the long run. I understand that what makes my front end 
successful might not make everyone's successful, but the union of all these
ideas will make everyone's front end successful. Therefor, I am offering up
at least the minimum amount of work that needs to be done to GDB in order to
make a front end successful, not just now, but in the future also.

   Michael noted some of the things I think a protocol should contain
   . The MI has an insufficient reflective interface.  
   . MI output changes from time to time.  Your proposal is to restrict
     the changes: fields can be added but not removed or modified;
     commands can be added and old commands deprecated.  
   . Inferior process output mixes with gdb output.

All of these issues are key to what I think a front end should expect from
GDB. However, I realize that none of these issues have anything to do with
XML. XML is just an obvious way to communicate data between to entities.

Jim suggested, 
   1) You can run gdb and use the tty command to send inferior output to a 
separate pty.  
   2) The XML output should just be another ui_out.  

   and some suggestions on commands sent from the front end to GDB.

Nick G suggested,
   Now for the real honesty:  I don't think an XML interface is going to
   fix the real problem.  The real problem is that GDB is not a library. 

Chris F suggested,
   He defiantly didn't see the benefit to switching to XMI, since XML is harder
   for him to understand than MI output.

I don't really know where to go from here. The XML change I think is a no brainer. 
It is a task that every front end writer in the future will be thankful for. Believe me,
no one is interested in parsing the MI output. It is a *complete waste of time*.
Next and more importantly, the versioning is a major hurdle for me in regards to MI. 
I think protocols should always be backwards compatible, it is a necessity for the 
client of the protocol. However, up till now I might be the only one making a big stink 
out of this, and therefor the versions are not backwards compatible. I believe CVS
snapshots and major releases should always adhere to the backwards compatibility test.
For example, I use CGDB with a version of GNAT's GDB and it works because A2 hasn't 
changed. I want to be able to use XMI with a 4 year old GDB, because the software world
is majorly screwed up, and sometimes I find myself having to work with ancient software.

If this document could be modified in any way, I would be more than glad to make an
initial effort at getting GDB/XMI going. I believe that all of the infrastructure for
the MI commands can stay in place, and like Jim said, a new ui_out  could be created.
A re-write from the MI is the worst idea in my opinion. I think that GDB is finally 
maturing a protocol that front end developers can not snicker at. I believe it should just
be modified in some ways and that XML would be a great plus for outputting data.

Finally, the difference between a text based protocol and a libgdb interface is irrelevant
to me. I would personally prefer the text based protocol at this point in time seeing that
there is no libgdb. What stopped the production of that effort? Also, making clients link
to the GDB they want to work with seems like a pain.

My proposal would be to make all of the infrastructure change to the MI code, not new code. 
Add validation, versioning, and maybe a new way besides the tty command to separate 
GDB output and the inferior output. Finally, add a new ui_out that outputs the commands in
XML. Thus, only adding the XML feature completely, otherwise, changing the process's of the 
MI to work the way I am suggesting.

Eagerly awaiting instructions :)

Thanks,
Bob Rossi

Re: GDB/XMI (XML Machine Interface)

[Nick NoSpam]

> it's easy to separate inferior I/O from the MI command stream.
Certainly there are methods, but the MI2 spec clearly defines how this
situation should be handled.  Apparently this is not a new issue, so
when MI2 was defined, inferior output was specifically handled via it's
own syntax.  So the problem is implementation (see bug 1654 from May). 
XML format won't cure this situation.

Regards,
Nick G.

On Wed, 2004-08-11 at 18:35, Jason Molenda wrote:
> Hi Alain,
> 
> On Aug 11, 2004, at 12:26 PM, Alain Magloire wrote:
> 
> > Doing a clean recursive decent parser for MI, is actually very 
> > simple...
> > it's just that you have to make n exceptions: inconsitencies, plain 
> > bugs,
> > crap etc .. the inferior output can be intertwine to the protocol, the 
> > duality CLI vs MI in an IDE, the OOB(async notifications) being 
> > incomplete, the inconsistensies between argument parsing etc ..
> 
> 
> I think both Chris and Jim mentioned this already, but it's easy to 
> separate inferior I/O from the MI command stream.  The UI sets up a 
> pseudo tty that it controls and uses the gdb "tty" command to redirect 
> inferior I/O to that ptty.  Our Xcode UI has been using this technique 
> for at least a couple of years now.
> 
> Jason

Re: GDB/XMI (XML Machine Interface)

[Felix Lee]

Chris Friesen <gdb001@speakeasy.net>:
> The code is an implementation that doesn't convey the objectives or 
> intent. Is that behavior a bug or feature in the code?

if a programmer isn't going to explain it in the code, why expect
them to explain it in a spec?  having a separate spec is like
removing comments from the source and putting them in a different
file, which introduces maintenance problems.  there's more chance
of code and description being in sync if they're "near" each
other, and extraction can be automated.

well, a spec is probably more closely related to testcases than
to implementation.  so perhaps in an ideal world, an interface
would be a single document that's easy to read, easy to parse,
and easy to test against.

(it's not clear to me that an xml dtd is any of those attributes,
but I don't have a strong objection to it.)
--

Re: GDB/XMI (XML Machine Interface)

[Jason Molenda]

Hi Alain,

On Aug 11, 2004, at 12:26 PM, Alain Magloire wrote:

> Doing a clean recursive decent parser for MI, is actually very 
> simple...
> it's just that you have to make n exceptions: inconsitencies, plain 
> bugs,
> crap etc .. the inferior output can be intertwine to the protocol, the 
> duality CLI vs MI in an IDE, the OOB(async notifications) being 
> incomplete, the inconsistensies between argument parsing etc ..


I think both Chris and Jim mentioned this already, but it's easy to 
separate inferior I/O from the MI command stream.  The UI sets up a 
pseudo tty that it controls and uses the gdb "tty" command to redirect 
inferior I/O to that ptty.  Our Xcode UI has been using this technique 
for at least a couple of years now.

Jason

Re: GDB/XMI (XML Machine Interface)

[Alain Magloire]

> 
> Hi,
> 
> Thanks to everyone that has looked at this RFC so far. I will leave the idea
> floating around for a few days to let everyone have a chance to
> respond. Then I will follow up the RFC with a summary of everyone's
> opinions.
> 
> I can see with the ideas given already, that if everyone contributes 
> (at least informationally), this RFC could be modified to fit into GDB
> very nicely.
> 

Nick "No spam" G. and other said something about this already .. I'll just reiterate.

The problem is not so much MI as a protocol then the implementation of MI in gdb 8-).
If you read the MI spec, it is not that bad .. actually very promising
and with the proposed changes from Andrew C and crew .. not bad at all.

MI did offer a consistent parsing vs protocol like Annoted {1,2}

Reality check, it hits you like a brick wall: the grand canyon between the documentation
vs actual implementation.
(some third parties like WindRiver or Apple seems to have "cleaner" implementation of MI).

Doing a clean recursive decent parser for MI, is actually very simple... 
it's just that you have to make n exceptions: inconsitencies, plain bugs,
crap etc .. the inferior output can be intertwine to the protocol, the duality CLI vs MI in an IDE,
the OOB(async notifications) being incomplete, the inconsistensies between argument parsing etc ..

Pros:
No doubt, XMI will offer an even more consistent parsing, it is a well know and formal language.
So the parsing will no longer be the focus (with all the available xml parsers) of problems.
The focus will be shift to more consistency of the data and folks can concentrate on
real issues(can we get notification for loading of dll or catch event implementation 8-) etc .. a good thing.

But whether XMI or MI the problems remains; a good implementation and resources to work on it.
GDB carries in its belly an enormous knowledge an heritage but that makes it also obese 8-(
most folks prefer to go around problems with yet another rewrite instead of digging in ...
Question: are you doing the same with this XMI proposal ? If yes you'll fall to the same trap
as MI and GDB will carry "yet another incomplete implementation" 8-)

Note:
don't get me wrong the RFC is pretty good, and for a Java programer, xml is pure symphony.

Re: GDB/XMI (XML Machine Interface)

[Bob Rossi]

Hi,

Thanks to everyone that has looked at this RFC so far. I will leave the idea
floating around for a few days to let everyone have a chance to
respond. Then I will follow up the RFC with a summary of everyone's
opinions.

I can see with the ideas given already, that if everyone contributes 
(at least informationally), this RFC could be modified to fit into GDB
very nicely.

Thanks,
Bob Rossi


On Tue, Aug 10, 2004 at 04:14:40PM -0400, Bob Rossi wrote:
> Hi,
> 
> As most of you know, I have been writing a front end to GDB called CGDB.
> However, for a while now, I have been a little disappointed with the MI
> interface. In my RFC I have described the problems I have with MI and I
> have proposed a new method of communication between GDB and the front
> end.
> 
> If there is good feedback on this RFC, I will continue research on it,
> filling in details that I thought would be best to wait until after an
> initial acceptance.
> 
> If the RFC is accepted by the community I plan on implementing an
> initial version of the XMI interface in GDB, and programming CGDB to 
> sit on top of GDB. This will at least give the community one open 
> source front end to GDB and an example to prove that the new 
> machine interface works.
> 
> I can't wait to hear your opinions/comments.
> 
> Thanks,
> Bob Rossi

Re: GDB/XMI (XML Machine Interface)

[Nick NoSpam]

First I'd like to commend you on the initiative to do something about
the MI problems.  I too have fiddled w/ a frontend and aun into a slew
of problems w/ MI2 (some of which made their way into the bug tracker
months ago w/out any attention).  I also have a great deal of experience
w/ XML (have used it for years and continue to do so at my job).

Now for the real honesty:  I don't think an XML interface is going to
fix the real problem.

Disclaimer:  I'm not an expert at GDB (it's internals nor usage) or GDB
MI.  The following is my candid opinion--it's too late (technically
early) to be tactful.

The real problem is that GDB is not a library.  It's a fairly convoluted
mess that uses the console as it's primary interface.  That is wrong. 
All abstractions and extensions (including MI*) work through the
console--essentially automating a user's keystrokes.  And there lies the
fundamental problem:  all methods of offering more than the console
interface are subject to the pitfalls of a console interface.  Michael
Chastain points out a popular one:  distinguishing GDB output from
inferior output.
What's worse, GDB has been massaged over time to be a one-size-fits-all
solution (ie. tightly coupled).  That's also wrong.  The problems of
which are evident when one tries to add or modify significant
functionality.

The time spent to generate a well-defined XML interface won't provide
much more than spending the same time improving the MI2 interface
(perhaps yielding MI3).  But neither of these approaches solves the real
problem outlined above.

So I think the best (and proper) thing to do is work on splitting GDB
into a separate, well-defined library.  Then, all interfaces (including
the console) are simply clients to this library.  At that time, an XML
interface would go further (as it adds language independence and
remoting).

A quick google search tells me I'm not the only one w/ this idea.  I
don't necessarily agree w/ the design of Andrew Cagney's libGDB, but the
idea is spot on:
http://sources.redhat.com/gdb/papers/libgdb2/

Regards,
Nick G.


On Tue, 2004-08-10 at 16:14, Bob Rossi wrote:
> Hi,
> 
> As most of you know, I have been writing a front end to GDB called CGDB.
> However, for a while now, I have been a little disappointed with the MI
> interface. In my RFC I have described the problems I have with MI and I
> have proposed a new method of communication between GDB and the front
> end.
> 
> If there is good feedback on this RFC, I will continue research on it,
> filling in details that I thought would be best to wait until after an
> initial acceptance.
> 
> If the RFC is accepted by the community I plan on implementing an
> initial version of the XMI interface in GDB, and programming CGDB to 
> sit on top of GDB. This will at least give the community one open 
> source front end to GDB and an example to prove that the new 
> machine interface works.
> 
> I can't wait to hear your opinions/comments.
> 
> Thanks,
> Bob Rossi
> 
>                        GDB/XMI (XML Machine Interface)
> 
>                                Robert Rossi
>                                August 2004
>                                bob@brasko.net
> 
> 
>                              TABLE OF CONTENTS
> 
> 1. Introduction
>   1.1 The Problem
>   1.2 The Objective
> 
> 2. The GDB/XMI Overview
>   2.1 Passing Information between GDB and the front end
>   2.2 Parsing XMI Commands from GDB's output
>   2.3 Parsing the Inferior's output
>   2.4 Validation
>   2.5 Version Management
>   2.6 Understanding the XML data
> 
> 3. GDB/XMI Specification
>   3.1 XMI Types
>     3.1.1 Scalar Types
>     3.1.2 Compound Types (Structs)
>   3.2 A Breakpoint Listing
>     3.2.1 The GDB/MI -break-list Specification
>     3.2.2 GDB/MI Output
>     3.2.3 The GDB/XMI Output
>   3.3 A Backtrace
>     3.3.1 The GDB/MI -stack-list-frames Specification
>     3.3.2 GDB/MI Output
>     3.3.3 The GDB/XMI Output
> 
> 4. A GDB/XMI Example
>   4.1 The Inferior's Code
>   4.2 GDB/MI Output
>   4.3 GDB/XMI Output
>   4.4 A Brief Description of the XMI output
>     4.4.1 GDB_DISPLAY_PROMPT Document
>     4.4.2 GDB_WAITING_FOR_COMMAND Document
>     4.4.3 The Front End Transmits a Command
>     4.4.4 GDB_INFERIOR_STARTED Document
>     4.4.5 GDB_INFERIOR_FINISHED Document
> 
> 5. Issues to resolve after RFC Initial approval.
>   5.1 If GDB will link to libxml, or just output XML
>   5.2 How the schema will represent each document sent to the front end
>   5.3 Separating GDB output and the Inferior output 
>   5.4 If GDB recieves commands in XML
> 
> Preface
> 
>   GDB/XMI is meant to be the successor of GDB/MI. It improves upon the
>   idea of GDB/MI and fixes many of the known issues that GDB/MI contains.
> 
> 1. Introduction
>   1.1 The Problem
> 
>   Writing a front end for GDB/MI means that a front end has to be able to
>   implement an ad hoc parser, capable of understanding all of the data 
>   sent from GDB to it. For each version of GDB, functionality might change, 
>   without ever allowing the GUI to understand what the interface differences
>   are in a scientific manner. Any guessing from version to version is a 
>   best-chance scenario, leaving the front end guessing what functionality
>   a CVS snapshot has that has been installed on any particular distribution.
> 
>   1.2 The Objective
> 
>   The objective of GDB/XMI is to create a reliable protocol between
>   GDB and the front end controlling GDB. A goal of this project is to
>   remove most of the parsing from the front end, and move it to a
>   reliable parsing library, capable of validating the data it is 
>   parsing, and building a tree representation of the data without 
>   any front end infrastructure. It is believed that the protocol between 
>   GDB and any front end can be automated in every front end and that it 
>   is not necessary to have any front end developer worry about the syntax
>   or grammar of the actual commands sent between GDB and the front end.
> 
>   Another goal of this project is to formalize the maintenance and
>   version management of the XMI commands, as GDB matures, and modifies the
>   XMI commands over time. The front end should be independent of the
>   XMI command versions, and should be able to determine what data is
>   available to it, without worrying about the version of any particular
>   XMI command.
>  
>   It is believed this can help front end writers in several ways. First,
>   there will be a significant reduction of time spent in parsing the 
>   obscure MI commands, and understanding what the output represents.
>   This gives front end developers a greater chance of actually getting
>   to 1.0 on any given front end, and allowing for much more time to 
>   be spent on the look & feel of the front end, not including the much
>   needed features that most front ends do not have. Secondly, It will
>   reduce the code size of each front end, potentially reducing the number 
>   of bugs, and allowing for a more reliable set of front ends that sit 
>   on top of GDB. 
> 
> 2. The GDB/XMI Overview
> 
>   GDB/XMI is based mostly on the model of GDB/MI. The major differences 
>   are the need to pass the information from GDB to the front end via XML
>   documents and the ability to give the front end a schema, capable 
>   of validating an XMI command.
> 
>   2.1 Passing Information between GDB and the front end
> 
>   All information passed between GDB and the front end is done in
>   the form of an XML document. Each XMI command, generates an XML
>   document, and is sent from GDB to the front end.
> 
>   2.2 Parsing XMI Commands from GDB's output
> 
>   XMI is the protocol between GDB and the front end. It is an XML
>   based Markup Language that is intended to be the Machine Interface
>   between GDB and any application that would like to communicate with it.
>   
>   An XML document is started and stopped with escape sequences. These
>   sequences tell the front end when an XML document is being sent, and
>   when the XML document is done being sent. For each XMI command, GDB 
>   will output an escape sequence saying that it is ready to transmit
>   the XML Document response. Then it will output the XML Document. Finally,
>   GDB will transmit another escape sequence, saying that the document 
>   has been completed. This allows the front end to understand what 
>   information to pass to the XML parser, and what information is output
>   from the inferior.
> 
>   2.3 Parsing the Inferior's output
>   
>   When the GDB sends the XML command stating that the inferior has started, 
>   the front end can then parse the output of GDB waiting for an escape
>   sequence, saying that the inferior has stopped running. All of the 
>   data captured between these two points are output from the inferior.
>   It can be processed real time and sent to the user to update them of what 
>   the inferior is doing. Any asynchronous commands can of course break the
>   stream and output data to the front end, and then notify the front end
>   that the inferior has started again. This easily allows the front end
>   to understand what data is from GDB and what data is from the inferior.
>   The only downside to this design is that escape sequences are needed.
>   However, the only way to change that is to allow the inferior's output
>   to be on a separate communication link (pipe) than the output of GDB.
>   So far, this has not happened. Section 5, point 3 illustrates that it
>   would be desirable to split GDB's and the inferior's output up, this
>   would cause the protocol between GDB and the front end to not include
>   the escape sequences before and after each XMI document sent.
> 
>   2.4 Validation
>   The validation document (DTD) has to be up to date with the XMI 
>   command for the particular version of GDB. Also, this document has to
>   be in one place. Therefore, I propose, that an XMI command be given to
>   output to the front end all of the XMI validation documents (DTD?) or
>   pass a parameter to have GDB output the validation document for a 
>   particular XMI command. This document will prove that the XMI commands
>   are valid, and GDB is not misbehaving. Front end writers can report
>   bad output from GDB easily, and the development process can self-adjust.
> 
>   The main goal of this tactic is that GDB is capable of telling front ends
>   if the output it is generating is correct. Front ends can use this 
>   capability, at virtually no extra cost, to determine if the protocol
>   between the two processes is incorrect. By allowing GDB to keep the 
>   Schema's, the DRY principle is honored, and things will not get out of
>   date.
> 
>   2.5 Version Management
> 
>   From version to version, XMI commands will be modified. Commands will
>   be fully backwards compatible, from version to version, allowing only
>   fields to be added, or providing more information than is already 
>   there. The front ends will not have to be updated in this way, 
>   allowing existing front ends to always be able to use at least the 
>   amount of information that they have been programmed to understand.
> 
>   Since it is not a perfect world, it is not always possible to make 
>   XMI commands backwards compatible. In this case, the XMI command to
>   be replaced will be marked as deprecated and a new XMI command will
>   be generated to take it's place. This new command will force the 
>   front end writer to program the functionality of the new command into
>   there program, and from then on, will again have a front end capable
>   of parsing the new command with a new GDB, and the old command with 
>   the old GDB.
> 
>   This model keeps front ends working with both old and new GDB's, which
>   is unfortunately a task that most front ends have to and should deal with.
> 
>   2.6 Understanding the XML data
> 
>   Since all commands are backwards compatible, the tree representation
>   for any XMI command can be walked the same way, no matter what version
>   of the XMI command is being used. The front end is capable of throwing
>   away any data that it does not know how or wish to process, allowing
>   it to pick and choose what data is appropriate.
> 
> 3. GDB/XMI Specification
> 
>   3.1 XMI Types
> 
>   The XMI types are to be used for validation purposes. They can also
>   be used to tell the front end what kind of type a particular element
>   is that GDB is sending to the front end.
> 
>   3.1.1 Scalar Types
> 
>   <int8>      one-byte singed integer
>   <uint8>     one-byte unsigned integer
>   <int16>     two-byte signed integer
>   <uint16>    two-byte unsigned integer
>   <int32>     four-byte signed integer
>   <uint32>    four-byte unsigned integer
>   <int64>     eight-byte signed integer
>   <uint64>    eight-byte unsigned integer
>   <boolean>   0 (false) or 1 (true)
>   <string>    string
>   <float>     single-precision signed floating point number
>   <double>    double-precision signed floating point number
> 
>   3.1.2 Compound Types (Structs)
> 
>   A "struct" is a compound value in which accessor name is the only 
>   distinction among member values, and no accessor has the same name 
>   as any other.
> 
>   <struct_example>
>     <element_one>one</element_one>
>     <element_two>two</element_two>
>     <element_three>three</element_three>
>   </struct_example>
> 
>   A Schema for such a struct could look like this.
> 
>   <element name="struct_example">
>     <complexType>
>       <element name="element_one" type="string"/>
>       <element name="element_two" type="string"/>
>       <element name="element_three" type="string"/>
>     </complexType>
>   </struct_example>
> 
>   3.2 A Breakpoint Listing
> 
>   3.2.1 The GDB/MI -break-list Specification
>   The -break-list Command
> 
>   Displays the list of inserted breakpoints, showing the following fields:
> 
>   `Number'
>     number of the breakpoint 
>   `Type'
>     type of the breakpoint: `breakpoint' or `watchpoint' 
>   `Disposition'
>     should the breakpoint be deleted or disabled when it is hit: 
>     `keep' or `nokeep' `Enabled' is the breakpoint enabled or no: 
>     `y' or `n' 
>   `Address'
>     memory location at which the breakpoint is set 
>   `What'
>     logical location of the breakpoint, expressed by function name, 
>     file name, line number 
>   `Times'
>     number of times the breakpoint has been hit 
> 
>   If there are no breakpoints or watchpoints, the BreakpointTable body 
>   field is an empty list. 
> 
>   3.2.2 GDB/MI Output
> 
>   -break-list
>   ^done,
>   BreakpointTable={
>     nr_rows="4",nr_cols="6",
>     hdr=[
>       {width="3",alignment="-1",col_name="number",colhdr="Num"},
>       {width="14",alignment="-1",col_name="type",colhdr="Type"},
>       {width="4",alignment="-1",col_name="disp",colhdr="Disp"},
>       {width="3",alignment="-1",col_name="enabled",colhdr="Enb"},
>       {width="10",alignment="-1",col_name="addr",colhdr="Address"},
>       {width="40",alignment="2",col_name="what",colhdr="What"}
>     ],
>     body=[
>       bkpt={
>         number="1",type="breakpoint",disp="keep",enabled="y",
>         addr="0x0804844f",func="main",file="test.c",line="35",times="1"},
>       bkpt={
>         number="2",type="breakpoint",disp="keep",enabled="y",
>         addr="0x080483ef",func="short_func",file="test.c",line="13",times="0"},
>       bkpt={
>         number="3",type="breakpoint",disp="keep",enabled="y",
>         addr="0x0804851d",func="main",file="test.c",line="61",times="0"},
>       bkpt={
>         number="4",type="hw watchpoint",disp="keep",enabled="y",addr="",
>         what="argc",times="0"}
>       ]
>     }
> 
>   3.2.3 The GDB/XMI Output
> 
>   <?xml version="1.0"?>
>   <breakpoints>
>     <breakpoint>
>       <number>1</number>
>       <type>breakpoint</type>
>       <disp>keep</disp>
>       <enabled>1</enabled>
>       <addr>0x0804844f</addr>
>       <func>main</func>
>       <file>test.c</file>
>       <line>35</line>
>       <times>0</times>
>     </breakpoint>
>     <breakpoint>
>       <number>2</number>
>       <type>breakpoint</type>
>       <disp>keep</disp>
>       <enabled>1</enabled>
>       <addr>0x080483ef</addr>
>       <func>short_func</func>
>       <file>test.c</file>
>       <line>13</line>
>       <times>0</times>
>     </breakpoint>
>     <breakpoint>
>       <number>3</number>
>       <type>breakpoint</type>
>       <disp>keep</disp>
>       <enabled>1</enabled>
>       <addr>0x0804851d</addr>
>       <func>main</func>
>       <file>test.c</file>
>       <line>61</line>
>       <times>0</times>
>     </breakpoint>
>     <watchpoint>
>       <number>4</number>
>       <type>watchpoint</type>
>       <disp>keep</disp>
>       <enabled>1</enabled>
>       <addr></addr>
>       <what>argc</what>
>       <times>0</times>
>     </watchpoint>
>   </breakpoints>
> 
>   3.3 A Backtrace
> 
>   3.3.1 The GDB/MI -stack-list-frames Specification
> 
>   The -stack-list-frames Command
> 
>   Synopsis: -stack-list-frames [ low-frame high-frame ]
> 
>   List the frames currently on the stack. For each frame it displays 
>   the following info:
> 
>   `level'
>     The frame number, 0 being the topmost frame, 
>     i.e. the innermost function. 
>   `addr'
>     The $pc value for that frame. 
>   `func'
>     Function name. 
>   `file'
>     File name of the source file where the function lives. 
>   `line'
>     Line number corresponding to the $pc. 
> 
>   If invoked without arguments, this command prints a backtrace for 
>   the whole stack. If given two integer arguments, it shows the frames 
>   whose levels are between the two arguments (inclusive). If the two 
>   arguments are equal, it shows the single frame at the corresponding level. 
> 
>   3.3.2 GDB/MI Output
> 
>   (gdb)
>   -stack-list-frames
>   ^done,stack=[frame={level="0",addr="0x080483ef",func="short_func",file="test.c",line="13"},frame={level="1",addr="0x080484f5",func="main",file="test.c",line="54"}]
> 
>   ^done,stack=[frame={level="0",addr="0x080483ef",func="short_func",
>   file="test.c",line="13"},frame={level="1",addr="0x080484f5",
>   func="main",file="test.c",line="54"}]
> 
>   3.3.3 The GDB/XMI Output
>     
>   <?xml version="1.0"?>
>   <stack>
>     <frame>
>       <level>0</level>
>       <addr>0x080483ef</addr>
>       <func>short_func</func>
>       <file>test.c</file>
>       <line>13</line>
>     </frame>
>     <frame>
>       <level>1</level>
>       <addr>0x080484f5</addr>
>       <func>main</func>
>       <file>test.c</file>
>       <line>54</line>
>     </frame>
>   </stack>
> 
> 4. A GDB/XMI Example
>   
>   4.1 The Inferior's Code
>   #include <stdio.h>
>   int main(int argc, char **argv){
>     printf ( "newline\n" e;
>     printf ( "nonewline" );
>     return 0;
>   }
> 
>   4.2 GDB/MI Output
>     (gdb)
>     -exec-run
>     ^running
>     (gdb)
>     newline
>     nonewline*stopped,reason="exited-normally"
>     (gdb)
> 
>   4.3 GDB/XMI Output
>   Assuming that the escape sequence is simply \027
>   The whitespace is not necessary, and is simply there for presentation.
> 
>   \027<GDB_DISPLAY_PROMPT>
>   (gdb) 
>   </GDB_DISPLAY_PROMPT>\027
>   \027<GDB_WAITING_FOR_COMMAND/>\027
>   -exec-run
>   \027<GDB_INFERIOR_STARTED/>\027
>   newline
>   nonewline\027<GDB_INFERIOR_FINISHED/>\027
>   \027<GDB_DISPLAY_PROMPT>
>   gdb
>   </GDB_DISPLAY_PROMPT>\027
>   \027<GDB_WAITING_FOR_COMMAND/>\027
> 
>   4.4 A Brief Description of the XMI output
>   
>     4.4.1 GDB_DISPLAY_PROMPT Document
>     The front end receives the document below.
>       \027<GDB_DISPLAY_PROMPT>
>       (gdb) 
>       </GDB_DISPLAY_PROMPT>\027
>     The front end sends the data to the XML processor, which then tells
>     it that the current prompt is "(gdb) ". The front end can choose to
>     do whatever it wants with this information, including display it to the
>     user, or just ignore it.
> 
>     4.4.2 GDB_WAITING_FOR_COMMAND Document
>     Next, GDB transmits the document below.
>       \027<GDB_WAITING_FOR_COMMAND/>\027
>     The front end receives the data and sends it to the XML processor. The
>     processor parses the document and the front end can determine that 
>     the command says that GDB is ready to accept a user command. At this
>     point, the front end understands that it is OK to transmit a command to
>     GDB.
> 
>     4.4.3 The Front End Transmits a Command
>     The front end transmits the command "-exec-run".
>     Should the front end transmit commands in XML or just 
>     ordinary text?
> 
>     4.4.4 GDB_INFERIOR_STARTED Document
>     GDB would send a document telling the front end that the inferior
>     has begun processing.
>       \027<GDB_INFERIOR_STARTED/>\027
>     Everything the front end processes from the pipe from this point 
>     until the next GDB XMI Document transmission is from the inferior.
>     It is considered to be output that the inferior would like to have
>     the user see. The front end can process this data realtime, since
>     it does not have to be sent to the XML parser for processing.
> 
>     The data
>       newline
>       nonewline
>       is outputted by the inferior, and the front end processes this data
>     realtime, understanding that it is not the output of GDB.
> 
>     4.4.5 GDB_INFERIOR_FINISHED Document
>     GDB would send a document telling the front end that the inferior
>     has finished processing.
>       \027<GDB_INFERIOR_FINISHED/>\027
> 
>     This alerts the front end that GDB is now outputting XMI commands
>     again. The front end no longer expects information from the inferior.
>     Optionally, GDB could output a XMI command stating that a signal 
>     has been caught, or some other asynchronous event has occurred. This
>     could be something like
>       \027<GDB_SIGNAL_CAUGHT>
>       <SIGNAL>
>         <NAME>SIGINT</NAME>
>         <NUMBER>2</NUMBER>
>         <COMMENT>Interrupt from keyboard</COMMENT>
>       </SIGNAL>
>       </GDB_SIGNAL_CAUGHT>\027
>     In this way, GDB could alert the front end of any asynchronous event,
>     and no special parsing mechanism will have to take place to 
>     understand such actions.
> 
> 5. Issues to resolve after RFC Initial approval.
> 
>   5.1 If GDB will link to libxml, or just output XML
>     It would be nice if GDB was capable of sending the XML documents by
>     creating them via libxml. However, libxml2 is licensed under the
>     MIT license. Also, I don't know if libxml2 is as portable as GDB.
> 
>   5.2 How the schema will represent each document sent to the front end
>     If there will be one schema for each XMI document, or a schema
>     that represents every XMI document.
> 
>   5.3 Separating GDB output and the Inferior output 
>     If GDB can output it's data on a different pipe than the 
>     inferior then the escape sequences would not be needed to tell
>     the front end which data is from GDB and which is from the inferior.
> 
>     This would simply the front end processing.
> 
>   5.4 If GDB recieves commands in XML
>     If GDB links in libxml2, then it could easy receive commands from the
>     front end in XML. This would be a nice feature, although, since the
>     parser in GDB is only written once, it doesn't really matter what format 
>     the commands are that is sent to it.

Re: GDB/XMI (XML Machine Interface)

[Chris Friesen]

The code is an implementation that doesn't convey the objectives or 
intent. Is that behavior a bug or feature in the code? It can be 
difficult to tell if there is not a description of what the code is 
supposed to do. The specification can set the objectives and intentions 
that define the bounds of the implementation, act as guidance for 
testing and other development. This is easier to do in writing than 
with code. A specification can be as specific or ambiguous as the 
writer desires, it's a balancing act depending on your needs.

Happy spec writing,
-ChrisF

On Aug 10, 2004, at 11:28 PM, Felix Lee wrote:

> Chris Friesen <gdb001@speakeasy.net>:
>> (The code is *not* the spec people...)
>
> code is usually less ambiguous than specs.  it's not clear to me
> that there's much point in making a spec for something that's
> likely to have only one implementation that will always have
> public source code.  well, isolating it as a spec should make
> some things easier, like the versioning issue.
>

Re: GDB/XMI (XML Machine Interface)

[Fabian Cenedese]

>                      GDB/XMI (XML Machine Interface)
>
>  3.2.1 The GDB/MI -break-list Specification
>  The -break-list Command
>
>  Displays the list of inserted breakpoints, showing the following fields:
>
>  `Number'
>    number of the breakpoint 
>  `Type'
>    type of the breakpoint: `breakpoint' or `watchpoint' 
>  `Disposition'
>    should the breakpoint be deleted or disabled when it is hit: 
>    `keep' or `nokeep' `Enabled' is the breakpoint enabled or no: 
>    `y' or `n' 
>  `Address'
>    memory location at which the breakpoint is set 
>  `What'
>    logical location of the breakpoint, expressed by function name, 
>    file name, line number 
>  `Times'
>    number of times the breakpoint has been hit 
>
>  If there are no breakpoints or watchpoints, the BreakpointTable body 
>  field is an empty list. 

I think there should be an additional field for the task id, indicating if it's
a general breakpoint (id=-1 or so) or a task-specific breakpoint.

bye  Fabi

Re: GDB/XMI (XML Machine Interface)

[Felix Lee]

Chris Friesen <gdb001@speakeasy.net>:
> (The code is *not* the spec people...)

code is usually less ambiguous than specs.  it's not clear to me
that there's much point in making a spec for something that's
likely to have only one implementation that will always have
public source code.  well, isolating it as a spec should make
some things easier, like the versioning issue.

I wish the world had settled on something other than XML.  it's a
lot harder to use than, say, LISP syntax, and libxml2 is about as
much code as a Common LISP implementation.  oh well.
--

Re: GDB/XMI (XML Machine Interface)

[Chris Friesen]

Hi Bob,

  	I'm not defending MI, I just haven't had any problems parsing MI  
output, mi0 or mi1, using Apple's branch of gdb. The structure is well  
defined and if you parse the payload into arrays and dictionaries then  
it's not so bad to deal with.

	The versioning problem you mention is solved by having a specification  
for backward compatibility and not by any inherent virtue of XML. (We  
could just add a version field to MI output...FYI: Apple's branch has  
an MI verify command to test for support of MI commands.) So I'm not  
sure what XML delivers for MI other than people can use a 'standard'  
parser. I guess the DTD's are a nice place for the spec of the MI  
commands and there are tools to help validate against them, so that's a  
win. (The code is *not* the spec people...)

> From: Bob Rossi <bob@brasko.net>
> Date: August 10, 2004 1:14:40 PM PDT
> To: gdb@sources.redhat.com
> Subject: GDB/XMI (XML Machine Interface)
>
> Hi,
>
> As most of you know, I have been writing a front end to GDB called  
> CGDB.
> However, for a while now, I have been a little disappointed with the MI
> interface. In my RFC I have described the problems I have with MI and I

>
>   1.2 The Objective
>
>   The objective of GDB/XMI is to create a reliable protocol between
>   GDB and the front end controlling GDB.

Is MI not reliable? Reliable is good.
>
> 2. The GDB/XMI Overview
>
>   2.1 Passing Information between GDB and the front end
>
>   All information passed between GDB and the front end is done in
>   the form of an XML document. Each XMI command, generates an XML
>   document, and is sent from GDB to the front end.
>

This would not be good for MI commands *to* gdb as developers of MI  
commands often enter them by hand.

>
>   2.5 Version Management
>
>   This model keeps front ends working with both old and new GDB's,  
> which
>   is unfortunately a task that most front ends have to and should deal  
> with.
>

I don't see a new IDE supporting an old GDB, it might with minimum  
version numbers for the MI commands, but the new IDE isn't going to  
support a deprecated command if they choose to use the new MI command.  
The IDE is going to choose features over using an old version of GDB.  
Backward compatibility of MI commands will make it so my old IDE can  
use a new GDB, which is more important.

>   3.3.2 GDB/MI Output
>
>   (gdb)
>   -stack-list-frames
>    
> ^done,stack=[frame={level="0",addr="0x080483ef",func="short_func",file= 
> "test.c",line="13"},frame={level="1",addr="0x080484f5",func="main",file 
> ="test.c",line="54"}]
>
>   ^done,stack=[frame={level="0",addr="0x080483ef",func="short_func",
>   file="test.c",line="13"},frame={level="1",addr="0x080484f5",
>   func="main",file="test.c",line="54"}]
>
>   3.3.3 The GDB/XMI Output
>
>   <?xml version="1.0"?>
>   <stack>
>     <frame>
>       <level>0</level>
>       <addr>0x080483ef</addr>
>       <func>short_func</func>
>       <file>test.c</file>
>       <line>13</line>
>     </frame>
>     <frame>
>       <level>1</level>
>       <addr>0x080484f5</addr>
>       <func>main</func>
>       <file>test.c</file>
>       <line>54</line>
>     </frame>
>   </stack>
>

<snip>

Hate to say this but the MI output is more human readable for 'key' and  
'value' (good for debugging) while the the XML is not friendly to my  
scanning... the MI reads more like code. If you look at it, the MI has  
the same tree structure as the XML, just written in a less pedantic  
form. An MI to XML formatter/converter wouldn't be that hard.

Overall MI suffers most from not having a specification for the various  
commands, as well as not documenting which platforms the commands are  
supported on. I don't see a big benefit from using XML. It could be  
tested by writing a simple MI to XML converter without having to make a  
lot of changes to gdb.

Cheers,
-ChrisF

Re: GDB/XMI (XML Machine Interface)

[Michael Chastain]

Interesting idea.  Here are my opinions.  This is real armchair stuff,
I've not an MI expert, but I've had a little experience with XML
(my test bed uses XML headers to track the hundreds of configurations
that I generate and test).  So these opinions are naive.

Pro XML:

  Standard libraries are available for reading XML.  This moves one
  level of parsing out of front end code into a standard library.

  DTD helps solve the versioning problem.

Con XML:

  MI already exists.

XML standardizes some of the lowest levels of the data interchange format.
But I get the impression that the problems you have are not at that level.
They are really one level up.  Problems like:

. The MI has an insufficient reflective interface.  That is, the front end
  cannot query GDB and find out the list of supported commands and the
  format of each command.  With XML, gdb could support commands to get
  the list of supported commands and a DTD for each command.

. MI output changes from time to time.  Your proposal is to restrict
  the changes: fields can be added but not removed or modified;
  commands can be added and old commands deprecated.  I think this
  sort of protocol evolution is XML-neutral, it's the same kind of
  restrictions whatever the data format.

. Inferior process output mixes with gdb output.  I don't think XML
  helps with this at all -- it's a problem at a lower level than the
  XML level.  Either open several streams, or emit some kind of packets
  on the single stream, with each packet tagged as "gdb output" or
  "inferior output".  XML is not very good for interpolating
  "inferior output" at random places in the XML stream.

From a higher view, adopting XML would force us to think about these
issues.  If a program writes XML then it's natural to expect the XML to
match some DTD, and then you start thinking about versioning the DTD,
and so on.  It's a cultural environment where the requirements that come
from the front end are a natural part of this environment.

As far as I can tell, and I'm no expert on MI, we could do most of these
things with the existing MI interface.  Separating inferior output from
gdb output is a different kind of problem, no matter what the data
interchange format.  But the reflective interface and the protocol
evolution could be done with MI.

We could identify the requirements and then make MI meet those
requirements, without going to XML data interchange format.  Or,
conversely, if we're having trouble with MI fields changing too much in
cvs gdb, then we're also at risk from the DTD changing too much in an
XML-based MI.

Michael C

Re: GDB/XMI (XML Machine Interface)

[Jim Ingham]

This seems like a worthy effort, since there are XML parsers out there 
for folks to use.

I have just a couple of comments about this.

1) You can run gdb and use the tty command to send inferior output to a 
separate pty.  That's what we do with Xcode, and it works fine.  This 
should work fine on all Unix systems, and under Cygwin.  We should use 
this solution to separate the output, and fix anywhere it doesn't work. 
  That seems much simpler than the whole escape code thing...

2) The XML output should just be another ui_out.  If there is any 
reason that the ui_out architecture doesn't support outputting XML, it 
should be enhanced to do that.  We definitely DON'T need another output 
gathering architecture (having now both ui_out and annotate...).  I 
think it should work pretty straightforwardly.  This will allow gdb to 
continue supporting the MI for any clients that use it while you are 
developing the XML version.  It should also mean that you can just plug 
in the XML version of the ui_out into the existing MI commands, so you 
could share the command implementations with the regular MI.

3) From our usage, the most annoying part of the MI is that the input 
command syntax is not well specified, and is still too much like a 
human interface (-break-insert should take -file & -line or -address, 
not rely solely on decode_line_1, there are still magic cookies all 
over the place, etc.)

The input is also where you need to be most careful about change in the 
commands.  Right now, if you add elements to the output, it is pretty 
easy to just ignore them.  But if you change the input, the UI usually 
does have to change to support them.  If more of the commands had a 
-flag value or similar structure, and were not order dependent, then 
you could ignore new options till you needed them, and it would be 
easier to write a robust driver.

So if you are really concerned about making a robust machine interface, 
I think you have to address the input side of things.

OTOH, as a developer of MI commands, you DO end up typing them into the 
MI a lot as you are working on gdb.  So I would not favor using XML 
input.  XML is very verbose, and having to type XML at gdb all the time 
would really drive me mad!  It is also overkill.  Some kind of flag 
value syntax would work just fine.

Jim

On Aug 10, 2004, at 3:38 PM, gdb-digest-help@sources.redhat.com wrote:

>
>
> Hi,
>
> As most of you know, I have been writing a front end to GDB called 
> CGDB.
> However, for a while now, I have been a little disappointed with the MI
> interface. In my RFC I have described the problems I have with MI and I
> have proposed a new method of communication between GDB and the front
> end.
>
> If there is good feedback on this RFC, I will continue research on it,
> filling in details that I thought would be best to wait until after an
> initial acceptance.
>
> If the RFC is accepted by the community I plan on implementing an
> initial version of the XMI interface in GDB, and programming CGDB to
> sit on top of GDB. This will at least give the community one open
> source front end to GDB and an example to prove that the new
> machine interface works.
>
> I can't wait to hear your opinions/comments.
>
> Thanks,
> Bob Rossi

Re: GDB/XMI (XML Machine Interface)

[Kip Macy]

Excellent. I've been thinking about the same thing for quite some time,
but have hesitated to propose it because of the animosity towards XML
that I see in many places in the OSS community. It seems that many
prefer to create a new format for every application.

The actual MI output is not anywhere nearly as clean as the grammar that
is documented. My parser (which I would not have had to spend days
writing and debugging if MI were XML) has a larger number of actions
than is documented. And yet there are still many cases that it cannot
handle.

I would eagerly support this effort.


					-Kip


On Tue, 10 Aug 2004, Bob Rossi wrote:

> Hi,
>
> As most of you know, I have been writing a front end to GDB called CGDB.
> However, for a while now, I have been a little disappointed with the MI
> interface. In my RFC I have described the problems I have with MI and I
> have proposed a new method of communication between GDB and the front
> end.
>
> If there is good feedback on this RFC, I will continue research on it,
> filling in details that I thought would be best to wait until after an
> initial acceptance.
>
> If the RFC is accepted by the community I plan on implementing an
> initial version of the XMI interface in GDB, and programming CGDB to
> sit on top of GDB. This will at least give the community one open
> source front end to GDB and an example to prove that the new
> machine interface works.
>
> I can't wait to hear your opinions/comments.
>
> Thanks,
> Bob Rossi
>
>                        GDB/XMI (XML Machine Interface)
>
>                                Robert Rossi
>                                August 2004
>                                bob@brasko.net
>
>
>                              TABLE OF CONTENTS
>
> 1. Introduction
>   1.1 The Problem
>   1.2 The Objective
>
> 2. The GDB/XMI Overview
>   2.1 Passing Information between GDB and the front end
>   2.2 Parsing XMI Commands from GDB's output
>   2.3 Parsing the Inferior's output
>   2.4 Validation
>   2.5 Version Management
>   2.6 Understanding the XML data
>
> 3. GDB/XMI Specification
>   3.1 XMI Types
>     3.1.1 Scalar Types
>     3.1.2 Compound Types (Structs)
>   3.2 A Breakpoint Listing
>     3.2.1 The GDB/MI -break-list Specification
>     3.2.2 GDB/MI Output
>     3.2.3 The GDB/XMI Output
>   3.3 A Backtrace
>     3.3.1 The GDB/MI -stack-list-frames Specification
>     3.3.2 GDB/MI Output
>     3.3.3 The GDB/XMI Output
>
> 4. A GDB/XMI Example
>   4.1 The Inferior's Code
>   4.2 GDB/MI Output
>   4.3 GDB/XMI Output
>   4.4 A Brief Description of the XMI output
>     4.4.1 GDB_DISPLAY_PROMPT Document
>     4.4.2 GDB_WAITING_FOR_COMMAND Document
>     4.4.3 The Front End Transmits a Command
>     4.4.4 GDB_INFERIOR_STARTED Document
>     4.4.5 GDB_INFERIOR_FINISHED Document
>
> 5. Issues to resolve after RFC Initial approval.
>   5.1 If GDB will link to libxml, or just output XML
>   5.2 How the schema will represent each document sent to the front end
>   5.3 Separating GDB output and the Inferior output
>   5.4 If GDB recieves commands in XML
>
> Preface
>
>   GDB/XMI is meant to be the successor of GDB/MI. It improves upon the
>   idea of GDB/MI and fixes many of the known issues that GDB/MI contains.
>
> 1. Introduction
>   1.1 The Problem
>
>   Writing a front end for GDB/MI means that a front end has to be able to
>   implement an ad hoc parser, capable of understanding all of the data
>   sent from GDB to it. For each version of GDB, functionality might change,
>   without ever allowing the GUI to understand what the interface differences
>   are in a scientific manner. Any guessing from version to version is a
>   best-chance scenario, leaving the front end guessing what functionality
>   a CVS snapshot has that has been installed on any particular distribution.
>
>   1.2 The Objective
>
>   The objective of GDB/XMI is to create a reliable protocol between
>   GDB and the front end controlling GDB. A goal of this project is to
>   remove most of the parsing from the front end, and move it to a
>   reliable parsing library, capable of validating the data it is
>   parsing, and building a tree representation of the data without
>   any front end infrastructure. It is believed that the protocol between
>   GDB and any front end can be automated in every front end and that it
>   is not necessary to have any front end developer worry about the syntax
>   or grammar of the actual commands sent between GDB and the front end.
>
>   Another goal of this project is to formalize the maintenance and
>   version management of the XMI commands, as GDB matures, and modifies the
>   XMI commands over time. The front end should be independent of the
>   XMI command versions, and should be able to determine what data is
>   available to it, without worrying about the version of any particular
>   XMI command.
>
>   It is believed this can help front end writers in several ways. First,
>   there will be a significant reduction of time spent in parsing the
>   obscure MI commands, and understanding what the output represents.
>   This gives front end developers a greater chance of actually getting
>   to 1.0 on any given front end, and allowing for much more time to
>   be spent on the look & feel of the front end, not including the much
>   needed features that most front ends do not have. Secondly, It will
>   reduce the code size of each front end, potentially reducing the number
>   of bugs, and allowing for a more reliable set of front ends that sit
>   on top of GDB.
>
> 2. The GDB/XMI Overview
>
>   GDB/XMI is based mostly on the model of GDB/MI. The major differences
>   are the need to pass the information from GDB to the front end via XML
>   documents and the ability to give the front end a schema, capable
>   of validating an XMI command.
>
>   2.1 Passing Information between GDB and the front end
>
>   All information passed between GDB and the front end is done in
>   the form of an XML document. Each XMI command, generates an XML
>   document, and is sent from GDB to the front end.
>
>   2.2 Parsing XMI Commands from GDB's output
>
>   XMI is the protocol between GDB and the front end. It is an XML
>   based Markup Language that is intended to be the Machine Interface
>   between GDB and any application that would like to communicate with it.
>
>   An XML document is started and stopped with escape sequences. These
>   sequences tell the front end when an XML document is being sent, and
>   when the XML document is done being sent. For each XMI command, GDB
>   will output an escape sequence saying that it is ready to transmit
>   the XML Document response. Then it will output the XML Document. Finally,
>   GDB will transmit another escape sequence, saying that the document
>   has been completed. This allows the front end to understand what
>   information to pass to the XML parser, and what information is output
>   from the inferior.
>
>   2.3 Parsing the Inferior's output
>
>   When the GDB sends the XML command stating that the inferior has started,
>   the front end can then parse the output of GDB waiting for an escape
>   sequence, saying that the inferior has stopped running. All of the
>   data captured between these two points are output from the inferior.
>   It can be processed real time and sent to the user to update them of what
>   the inferior is doing. Any asynchronous commands can of course break the
>   stream and output data to the front end, and then notify the front end
>   that the inferior has started again. This easily allows the front end
>   to understand what data is from GDB and what data is from the inferior.
>   The only downside to this design is that escape sequences are needed.
>   However, the only way to change that is to allow the inferior's output
>   to be on a separate communication link (pipe) than the output of GDB.
>   So far, this has not happened. Section 5, point 3 illustrates that it
>   would be desirable to split GDB's and the inferior's output up, this
>   would cause the protocol between GDB and the front end to not include
>   the escape sequences before and after each XMI document sent.
>
>   2.4 Validation
>   The validation document (DTD) has to be up to date with the XMI
>   command for the particular version of GDB. Also, this document has to
>   be in one place. Therefore, I propose, that an XMI command be given to
>   output to the front end all of the XMI validation documents (DTD?) or
>   pass a parameter to have GDB output the validation document for a
>   particular XMI command. This document will prove that the XMI commands
>   are valid, and GDB is not misbehaving. Front end writers can report
>   bad output from GDB easily, and the development process can self-adjust.
>
>   The main goal of this tactic is that GDB is capable of telling front ends
>   if the output it is generating is correct. Front ends can use this
>   capability, at virtually no extra cost, to determine if the protocol
>   between the two processes is incorrect. By allowing GDB to keep the
>   Schema's, the DRY principle is honored, and things will not get out of
>   date.
>
>   2.5 Version Management
>
>   From version to version, XMI commands will be modified. Commands will
>   be fully backwards compatible, from version to version, allowing only
>   fields to be added, or providing more information than is already
>   there. The front ends will not have to be updated in this way,
>   allowing existing front ends to always be able to use at least the
>   amount of information that they have been programmed to understand.
>
>   Since it is not a perfect world, it is not always possible to make
>   XMI commands backwards compatible. In this case, the XMI command to
>   be replaced will be marked as deprecated and a new XMI command will
>   be generated to take it's place. This new command will force the
>   front end writer to program the functionality of the new command into
>   there program, and from then on, will again have a front end capable
>   of parsing the new command with a new GDB, and the old command with
>   the old GDB.
>
>   This model keeps front ends working with both old and new GDB's, which
>   is unfortunately a task that most front ends have to and should deal with.
>
>   2.6 Understanding the XML data
>
>   Since all commands are backwards compatible, the tree representation
>   for any XMI command can be walked the same way, no matter what version
>   of the XMI command is being used. The front end is capable of throwing
>   away any data that it does not know how or wish to process, allowing
>   it to pick and choose what data is appropriate.
>
> 3. GDB/XMI Specification
>
>   3.1 XMI Types
>
>   The XMI types are to be used for validation purposes. They can also
>   be used to tell the front end what kind of type a particular element
>   is that GDB is sending to the front end.
>
>   3.1.1 Scalar Types
>
>   <int8>      one-byte singed integer
>   <uint8>     one-byte unsigned integer
>   <int16>     two-byte signed integer
>   <uint16>    two-byte unsigned integer
>   <int32>     four-byte signed integer
>   <uint32>    four-byte unsigned integer
>   <int64>     eight-byte signed integer
>   <uint64>    eight-byte unsigned integer
>   <boolean>   0 (false) or 1 (true)
>   <string>    string
>   <float>     single-precision signed floating point number
>   <double>    double-precision signed floating point number
>
>   3.1.2 Compound Types (Structs)
>
>   A "struct" is a compound value in which accessor name is the only
>   distinction among member values, and no accessor has the same name
>   as any other.
>
>   <struct_example>
>     <element_one>one</element_one>
>     <element_two>two</element_two>
>     <element_three>three</element_three>
>   </struct_example>
>
>   A Schema for such a struct could look like this.
>
>   <element name="struct_example">
>     <complexType>
>       <element name="element_one" type="string"/>
>       <element name="element_two" type="string"/>
>       <element name="element_three" type="string"/>
>     </complexType>
>   </struct_example>
>
>   3.2 A Breakpoint Listing
>
>   3.2.1 The GDB/MI -break-list Specification
>   The -break-list Command
>
>   Displays the list of inserted breakpoints, showing the following fields:
>
>   `Number'
>     number of the breakpoint
>   `Type'
>     type of the breakpoint: `breakpoint' or `watchpoint'
>   `Disposition'
>     should the breakpoint be deleted or disabled when it is hit:
>     `keep' or `nokeep' `Enabled' is the breakpoint enabled or no:
>     `y' or `n'
>   `Address'
>     memory location at which the breakpoint is set
>   `What'
>     logical location of the breakpoint, expressed by function name,
>     file name, line number
>   `Times'
>     number of times the breakpoint has been hit
>
>   If there are no breakpoints or watchpoints, the BreakpointTable body
>   field is an empty list.
>
>   3.2.2 GDB/MI Output
>
>   -break-list
>   ^done,
>   BreakpointTable={
>     nr_rows="4",nr_cols="6",
>     hdr=[
>       {width="3",alignment="-1",col_name="number",colhdr="Num"},
>       {width="14",alignment="-1",col_name="type",colhdr="Type"},
>       {width="4",alignment="-1",col_name="disp",colhdr="Disp"},
>       {width="3",alignment="-1",col_name="enabled",colhdr="Enb"},
>       {width="10",alignment="-1",col_name="addr",colhdr="Address"},
>       {width="40",alignment="2",col_name="what",colhdr="What"}
>     ],
>     body=[
>       bkpt={
>         number="1",type="breakpoint",disp="keep",enabled="y",
>         addr="0x0804844f",func="main",file="test.c",line="35",times="1"},
>       bkpt={
>         number="2",type="breakpoint",disp="keep",enabled="y",
>         addr="0x080483ef",func="short_func",file="test.c",line="13",times="0"},
>       bkpt={
>         number="3",type="breakpoint",disp="keep",enabled="y",
>         addr="0x0804851d",func="main",file="test.c",line="61",times="0"},
>       bkpt={
>         number="4",type="hw watchpoint",disp="keep",enabled="y",addr="",
>         what="argc",times="0"}
>       ]
>     }
>
>   3.2.3 The GDB/XMI Output
>
>   <?xml version="1.0"?>
>   <breakpoints>
>     <breakpoint>
>       <number>1</number>
>       <type>breakpoint</type>
>       <disp>keep</disp>
>       <enabled>1</enabled>
>       <addr>0x0804844f</addr>
>       <func>main</func>
>       <file>test.c</file>
>       <line>35</line>
>       <times>0</times>
>     </breakpoint>
>     <breakpoint>
>       <number>2</number>
>       <type>breakpoint</type>
>       <disp>keep</disp>
>       <enabled>1</enabled>
>       <addr>0x080483ef</addr>
>       <func>short_func</func>
>       <file>test.c</file>
>       <line>13</line>
>       <times>0</times>
>     </breakpoint>
>     <breakpoint>
>       <number>3</number>
>       <type>breakpoint</type>
>       <disp>keep</disp>
>       <enabled>1</enabled>
>       <addr>0x0804851d</addr>
>       <func>main</func>
>       <file>test.c</file>
>       <line>61</line>
>       <times>0</times>
>     </breakpoint>
>     <watchpoint>
>       <number>4</number>
>       <type>watchpoint</type>
>       <disp>keep</disp>
>       <enabled>1</enabled>
>       <addr></addr>
>       <what>argc</what>
>       <times>0</times>
>     </watchpoint>
>   </breakpoints>
>
>   3.3 A Backtrace
>
>   3.3.1 The GDB/MI -stack-list-frames Specification
>
>   The -stack-list-frames Command
>
>   Synopsis: -stack-list-frames [ low-frame high-frame ]
>
>   List the frames currently on the stack. For each frame it displays
>   the following info:
>
>   `level'
>     The frame number, 0 being the topmost frame,
>     i.e. the innermost function.
>   `addr'
>     The $pc value for that frame.
>   `func'
>     Function name.
>   `file'
>     File name of the source file where the function lives.
>   `line'
>     Line number corresponding to the $pc.
>
>   If invoked without arguments, this command prints a backtrace for
>   the whole stack. If given two integer arguments, it shows the frames
>   whose levels are between the two arguments (inclusive). If the two
>   arguments are equal, it shows the single frame at the corresponding level.
>
>   3.3.2 GDB/MI Output
>
>   (gdb)
>   -stack-list-frames
>   ^done,stack=[frame={level="0",addr="0x080483ef",func="short_func",file="test.c",line="13"},frame={level="1",addr="0x080484f5",func="main",file="test.c",line="54"}]
>
>   ^done,stack=[frame={level="0",addr="0x080483ef",func="short_func",
>   file="test.c",line="13"},frame={level="1",addr="0x080484f5",
>   func="main",file="test.c",line="54"}]
>
>   3.3.3 The GDB/XMI Output
>
>   <?xml version="1.0"?>
>   <stack>
>     <frame>
>       <level>0</level>
>       <addr>0x080483ef</addr>
>       <func>short_func</func>
>       <file>test.c</file>
>       <line>13</line>
>     </frame>
>     <frame>
>       <level>1</level>
>       <addr>0x080484f5</addr>
>       <func>main</func>
>       <file>test.c</file>
>       <line>54</line>
>     </frame>
>   </stack>
>
> 4. A GDB/XMI Example
>
>   4.1 The Inferior's Code
>   #include <stdio.h>
>   int main(int argc, char **argv){
>     printf ( "newline\n" e;
>     printf ( "nonewline" );
>     return 0;
>   }
>
>   4.2 GDB/MI Output
>     (gdb)
>     -exec-run
>     ^running
>     (gdb)
>     newline
>     nonewline*stopped,reason="exited-normally"
>     (gdb)
>
>   4.3 GDB/XMI Output
>   Assuming that the escape sequence is simply \027
>   The whitespace is not necessary, and is simply there for presentation.
>
>   \027<GDB_DISPLAY_PROMPT>
>   (gdb)
>   </GDB_DISPLAY_PROMPT>\027
>   \027<GDB_WAITING_FOR_COMMAND/>\027
>   -exec-run
>   \027<GDB_INFERIOR_STARTED/>\027
>   newline
>   nonewline\027<GDB_INFERIOR_FINISHED/>\027
>   \027<GDB_DISPLAY_PROMPT>
>   gdb
>   </GDB_DISPLAY_PROMPT>\027
>   \027<GDB_WAITING_FOR_COMMAND/>\027
>
>   4.4 A Brief Description of the XMI output
>
>     4.4.1 GDB_DISPLAY_PROMPT Document
>     The front end receives the document below.
>       \027<GDB_DISPLAY_PROMPT>
>       (gdb)
>       </GDB_DISPLAY_PROMPT>\027
>     The front end sends the data to the XML processor, which then tells
>     it that the current prompt is "(gdb) ". The front end can choose to
>     do whatever it wants with this information, including display it to the
>     user, or just ignore it.
>
>     4.4.2 GDB_WAITING_FOR_COMMAND Document
>     Next, GDB transmits the document below.
>       \027<GDB_WAITING_FOR_COMMAND/>\027
>     The front end receives the data and sends it to the XML processor. The
>     processor parses the document and the front end can determine that
>     the command says that GDB is ready to accept a user command. At this
>     point, the front end understands that it is OK to transmit a command to
>     GDB.
>
>     4.4.3 The Front End Transmits a Command
>     The front end transmits the command "-exec-run".
>     Should the front end transmit commands in XML or just
>     ordinary text?
>
>     4.4.4 GDB_INFERIOR_STARTED Document
>     GDB would send a document telling the front end that the inferior
>     has begun processing.
>       \027<GDB_INFERIOR_STARTED/>\027
>     Everything the front end processes from the pipe from this point
>     until the next GDB XMI Document transmission is from the inferior.
>     It is considered to be output that the inferior would like to have
>     the user see. The front end can process this data realtime, since
>     it does not have to be sent to the XML parser for processing.
>
>     The data
>       newline
>       nonewline
>       is outputted by the inferior, and the front end processes this data
>     realtime, understanding that it is not the output of GDB.
>
>     4.4.5 GDB_INFERIOR_FINISHED Document
>     GDB would send a document telling the front end that the inferior
>     has finished processing.
>       \027<GDB_INFERIOR_FINISHED/>\027
>
>     This alerts the front end that GDB is now outputting XMI commands
>     again. The front end no longer expects information from the inferior.
>     Optionally, GDB could output a XMI command stating that a signal
>     has been caught, or some other asynchronous event has occurred. This
>     could be something like
>       \027<GDB_SIGNAL_CAUGHT>
>       <SIGNAL>
>         <NAME>SIGINT</NAME>
>         <NUMBER>2</NUMBER>
>         <COMMENT>Interrupt from keyboard</COMMENT>
>       </SIGNAL>
>       </GDB_SIGNAL_CAUGHT>\027
>     In this way, GDB could alert the front end of any asynchronous event,
>     and no special parsing mechanism will have to take place to
>     understand such actions.
>
> 5. Issues to resolve after RFC Initial approval.
>
>   5.1 If GDB will link to libxml, or just output XML
>     It would be nice if GDB was capable of sending the XML documents by
>     creating them via libxml. However, libxml2 is licensed under the
>     MIT license. Also, I don't know if libxml2 is as portable as GDB.
>
>   5.2 How the schema will represent each document sent to the front end
>     If there will be one schema for each XMI document, or a schema
>     that represents every XMI document.
>
>   5.3 Separating GDB output and the Inferior output
>     If GDB can output it's data on a different pipe than the
>     inferior then the escape sequences would not be needed to tell
>     the front end which data is from GDB and which is from the inferior.
>
>     This would simply the front end processing.
>
>   5.4 If GDB recieves commands in XML
>     If GDB links in libxml2, then it could easy receive commands from the
>     front end in XML. This would be a nice feature, although, since the
>     parser in GDB is only written once, it doesn't really matter what format
>     the commands are that is sent to it.
>

GDB/XMI (XML Machine Interface)

[Bob Rossi]

Hi,

As most of you know, I have been writing a front end to GDB called CGDB.
However, for a while now, I have been a little disappointed with the MI
interface. In my RFC I have described the problems I have with MI and I
have proposed a new method of communication between GDB and the front
end.

If there is good feedback on this RFC, I will continue research on it,
filling in details that I thought would be best to wait until after an
initial acceptance.

If the RFC is accepted by the community I plan on implementing an
initial version of the XMI interface in GDB, and programming CGDB to 
sit on top of GDB. This will at least give the community one open 
source front end to GDB and an example to prove that the new 
machine interface works.

I can't wait to hear your opinions/comments.

Thanks,
Bob Rossi

                       GDB/XMI (XML Machine Interface)

                               Robert Rossi
                               August 2004
                               bob@brasko.net


                             TABLE OF CONTENTS

1. Introduction
  1.1 The Problem
  1.2 The Objective

2. The GDB/XMI Overview
  2.1 Passing Information between GDB and the front end
  2.2 Parsing XMI Commands from GDB's output
  2.3 Parsing the Inferior's output
  2.4 Validation
  2.5 Version Management
  2.6 Understanding the XML data

3. GDB/XMI Specification
  3.1 XMI Types
    3.1.1 Scalar Types
    3.1.2 Compound Types (Structs)
  3.2 A Breakpoint Listing
    3.2.1 The GDB/MI -break-list Specification
    3.2.2 GDB/MI Output
    3.2.3 The GDB/XMI Output
  3.3 A Backtrace
    3.3.1 The GDB/MI -stack-list-frames Specification
    3.3.2 GDB/MI Output
    3.3.3 The GDB/XMI Output

4. A GDB/XMI Example
  4.1 The Inferior's Code
  4.2 GDB/MI Output
  4.3 GDB/XMI Output
  4.4 A Brief Description of the XMI output
    4.4.1 GDB_DISPLAY_PROMPT Document
    4.4.2 GDB_WAITING_FOR_COMMAND Document
    4.4.3 The Front End Transmits a Command
    4.4.4 GDB_INFERIOR_STARTED Document
    4.4.5 GDB_INFERIOR_FINISHED Document

5. Issues to resolve after RFC Initial approval.
  5.1 If GDB will link to libxml, or just output XML
  5.2 How the schema will represent each document sent to the front end
  5.3 Separating GDB output and the Inferior output 
  5.4 If GDB recieves commands in XML

Preface

  GDB/XMI is meant to be the successor of GDB/MI. It improves upon the
  idea of GDB/MI and fixes many of the known issues that GDB/MI contains.

1. Introduction
  1.1 The Problem

  Writing a front end for GDB/MI means that a front end has to be able to
  implement an ad hoc parser, capable of understanding all of the data 
  sent from GDB to it. For each version of GDB, functionality might change, 
  without ever allowing the GUI to understand what the interface differences
  are in a scientific manner. Any guessing from version to version is a 
  best-chance scenario, leaving the front end guessing what functionality
  a CVS snapshot has that has been installed on any particular distribution.

  1.2 The Objective

  The objective of GDB/XMI is to create a reliable protocol between
  GDB and the front end controlling GDB. A goal of this project is to
  remove most of the parsing from the front end, and move it to a
  reliable parsing library, capable of validating the data it is 
  parsing, and building a tree representation of the data without 
  any front end infrastructure. It is believed that the protocol between 
  GDB and any front end can be automated in every front end and that it 
  is not necessary to have any front end developer worry about the syntax
  or grammar of the actual commands sent between GDB and the front end.

  Another goal of this project is to formalize the maintenance and
  version management of the XMI commands, as GDB matures, and modifies the
  XMI commands over time. The front end should be independent of the
  XMI command versions, and should be able to determine what data is
  available to it, without worrying about the version of any particular
  XMI command.
 
  It is believed this can help front end writers in several ways. First,
  there will be a significant reduction of time spent in parsing the 
  obscure MI commands, and understanding what the output represents.
  This gives front end developers a greater chance of actually getting
  to 1.0 on any given front end, and allowing for much more time to 
  be spent on the look & feel of the front end, not including the much
  needed features that most front ends do not have. Secondly, It will
  reduce the code size of each front end, potentially reducing the number 
  of bugs, and allowing for a more reliable set of front ends that sit 
  on top of GDB. 

2. The GDB/XMI Overview

  GDB/XMI is based mostly on the model of GDB/MI. The major differences 
  are the need to pass the information from GDB to the front end via XML
  documents and the ability to give the front end a schema, capable 
  of validating an XMI command.

  2.1 Passing Information between GDB and the front end

  All information passed between GDB and the front end is done in
  the form of an XML document. Each XMI command, generates an XML
  document, and is sent from GDB to the front end.

  2.2 Parsing XMI Commands from GDB's output

  XMI is the protocol between GDB and the front end. It is an XML
  based Markup Language that is intended to be the Machine Interface
  between GDB and any application that would like to communicate with it.
  
  An XML document is started and stopped with escape sequences. These
  sequences tell the front end when an XML document is being sent, and
  when the XML document is done being sent. For each XMI command, GDB 
  will output an escape sequence saying that it is ready to transmit
  the XML Document response. Then it will output the XML Document. Finally,
  GDB will transmit another escape sequence, saying that the document 
  has been completed. This allows the front end to understand what 
  information to pass to the XML parser, and what information is output
  from the inferior.

  2.3 Parsing the Inferior's output
  
  When the GDB sends the XML command stating that the inferior has started, 
  the front end can then parse the output of GDB waiting for an escape
  sequence, saying that the inferior has stopped running. All of the 
  data captured between these two points are output from the inferior.
  It can be processed real time and sent to the user to update them of what 
  the inferior is doing. Any asynchronous commands can of course break the
  stream and output data to the front end, and then notify the front end
  that the inferior has started again. This easily allows the front end
  to understand what data is from GDB and what data is from the inferior.
  The only downside to this design is that escape sequences are needed.
  However, the only way to change that is to allow the inferior's output
  to be on a separate communication link (pipe) than the output of GDB.
  So far, this has not happened. Section 5, point 3 illustrates that it
  would be desirable to split GDB's and the inferior's output up, this
  would cause the protocol between GDB and the front end to not include
  the escape sequences before and after each XMI document sent.

  2.4 Validation
  The validation document (DTD) has to be up to date with the XMI 
  command for the particular version of GDB. Also, this document has to
  be in one place. Therefore, I propose, that an XMI command be given to
  output to the front end all of the XMI validation documents (DTD?) or
  pass a parameter to have GDB output the validation document for a 
  particular XMI command. This document will prove that the XMI commands
  are valid, and GDB is not misbehaving. Front end writers can report
  bad output from GDB easily, and the development process can self-adjust.

  The main goal of this tactic is that GDB is capable of telling front ends
  if the output it is generating is correct. Front ends can use this 
  capability, at virtually no extra cost, to determine if the protocol
  between the two processes is incorrect. By allowing GDB to keep the 
  Schema's, the DRY principle is honored, and things will not get out of
  date.

  2.5 Version Management

  From version to version, XMI commands will be modified. Commands will
  be fully backwards compatible, from version to version, allowing only
  fields to be added, or providing more information than is already 
  there. The front ends will not have to be updated in this way, 
  allowing existing front ends to always be able to use at least the 
  amount of information that they have been programmed to understand.

  Since it is not a perfect world, it is not always possible to make 
  XMI commands backwards compatible. In this case, the XMI command to
  be replaced will be marked as deprecated and a new XMI command will
  be generated to take it's place. This new command will force the 
  front end writer to program the functionality of the new command into
  there program, and from then on, will again have a front end capable
  of parsing the new command with a new GDB, and the old command with 
  the old GDB.

  This model keeps front ends working with both old and new GDB's, which
  is unfortunately a task that most front ends have to and should deal with.

  2.6 Understanding the XML data

  Since all commands are backwards compatible, the tree representation
  for any XMI command can be walked the same way, no matter what version
  of the XMI command is being used. The front end is capable of throwing
  away any data that it does not know how or wish to process, allowing
  it to pick and choose what data is appropriate.

3. GDB/XMI Specification

  3.1 XMI Types

  The XMI types are to be used for validation purposes. They can also
  be used to tell the front end what kind of type a particular element
  is that GDB is sending to the front end.

  3.1.1 Scalar Types

  <int8>      one-byte singed integer
  <uint8>     one-byte unsigned integer
  <int16>     two-byte signed integer
  <uint16>    two-byte unsigned integer
  <int32>     four-byte signed integer
  <uint32>    four-byte unsigned integer
  <int64>     eight-byte signed integer
  <uint64>    eight-byte unsigned integer
  <boolean>   0 (false) or 1 (true)
  <string>    string
  <float>     single-precision signed floating point number
  <double>    double-precision signed floating point number

  3.1.2 Compound Types (Structs)

  A "struct" is a compound value in which accessor name is the only 
  distinction among member values, and no accessor has the same name 
  as any other.

  <struct_example>
    <element_one>one</element_one>
    <element_two>two</element_two>
    <element_three>three</element_three>
  </struct_example>

  A Schema for such a struct could look like this.

  <element name="struct_example">
    <complexType>
      <element name="element_one" type="string"/>
      <element name="element_two" type="string"/>
      <element name="element_three" type="string"/>
    </complexType>
  </struct_example>

  3.2 A Breakpoint Listing

  3.2.1 The GDB/MI -break-list Specification
  The -break-list Command

  Displays the list of inserted breakpoints, showing the following fields:

  `Number'
    number of the breakpoint 
  `Type'
    type of the breakpoint: `breakpoint' or `watchpoint' 
  `Disposition'
    should the breakpoint be deleted or disabled when it is hit: 
    `keep' or `nokeep' `Enabled' is the breakpoint enabled or no: 
    `y' or `n' 
  `Address'
    memory location at which the breakpoint is set 
  `What'
    logical location of the breakpoint, expressed by function name, 
    file name, line number 
  `Times'
    number of times the breakpoint has been hit 

  If there are no breakpoints or watchpoints, the BreakpointTable body 
  field is an empty list. 

  3.2.2 GDB/MI Output

  -break-list
  ^done,
  BreakpointTable={
    nr_rows="4",nr_cols="6",
    hdr=[
      {width="3",alignment="-1",col_name="number",colhdr="Num"},
      {width="14",alignment="-1",col_name="type",colhdr="Type"},
      {width="4",alignment="-1",col_name="disp",colhdr="Disp"},
      {width="3",alignment="-1",col_name="enabled",colhdr="Enb"},
      {width="10",alignment="-1",col_name="addr",colhdr="Address"},
      {width="40",alignment="2",col_name="what",colhdr="What"}
    ],
    body=[
      bkpt={
        number="1",type="breakpoint",disp="keep",enabled="y",
        addr="0x0804844f",func="main",file="test.c",line="35",times="1"},
      bkpt={
        number="2",type="breakpoint",disp="keep",enabled="y",
        addr="0x080483ef",func="short_func",file="test.c",line="13",times="0"},
      bkpt={
        number="3",type="breakpoint",disp="keep",enabled="y",
        addr="0x0804851d",func="main",file="test.c",line="61",times="0"},
      bkpt={
        number="4",type="hw watchpoint",disp="keep",enabled="y",addr="",
        what="argc",times="0"}
      ]
    }

  3.2.3 The GDB/XMI Output

  <?xml version="1.0"?>
  <breakpoints>
    <breakpoint>
      <number>1</number>
      <type>breakpoint</type>
      <disp>keep</disp>
      <enabled>1</enabled>
      <addr>0x0804844f</addr>
      <func>main</func>
      <file>test.c</file>
      <line>35</line>
      <times>0</times>
    </breakpoint>
    <breakpoint>
      <number>2</number>
      <type>breakpoint</type>
      <disp>keep</disp>
      <enabled>1</enabled>
      <addr>0x080483ef</addr>
      <func>short_func</func>
      <file>test.c</file>
      <line>13</line>
      <times>0</times>
    </breakpoint>
    <breakpoint>
      <number>3</number>
      <type>breakpoint</type>
      <disp>keep</disp>
      <enabled>1</enabled>
      <addr>0x0804851d</addr>
      <func>main</func>
      <file>test.c</file>
      <line>61</line>
      <times>0</times>
    </breakpoint>
    <watchpoint>
      <number>4</number>
      <type>watchpoint</type>
      <disp>keep</disp>
      <enabled>1</enabled>
      <addr></addr>
      <what>argc</what>
      <times>0</times>
    </watchpoint>
  </breakpoints>

  3.3 A Backtrace

  3.3.1 The GDB/MI -stack-list-frames Specification

  The -stack-list-frames Command

  Synopsis: -stack-list-frames [ low-frame high-frame ]

  List the frames currently on the stack. For each frame it displays 
  the following info:

  `level'
    The frame number, 0 being the topmost frame, 
    i.e. the innermost function. 
  `addr'
    The $pc value for that frame. 
  `func'
    Function name. 
  `file'
    File name of the source file where the function lives. 
  `line'
    Line number corresponding to the $pc. 

  If invoked without arguments, this command prints a backtrace for 
  the whole stack. If given two integer arguments, it shows the frames 
  whose levels are between the two arguments (inclusive). If the two 
  arguments are equal, it shows the single frame at the corresponding level. 

  3.3.2 GDB/MI Output

  (gdb)
  -stack-list-frames
  ^done,stack=[frame={level="0",addr="0x080483ef",func="short_func",file="test.c",line="13"},frame={level="1",addr="0x080484f5",func="main",file="test.c",line="54"}]

  ^done,stack=[frame={level="0",addr="0x080483ef",func="short_func",
  file="test.c",line="13"},frame={level="1",addr="0x080484f5",
  func="main",file="test.c",line="54"}]

  3.3.3 The GDB/XMI Output
    
  <?xml version="1.0"?>
  <stack>
    <frame>
      <level>0</level>
      <addr>0x080483ef</addr>
      <func>short_func</func>
      <file>test.c</file>
      <line>13</line>
    </frame>
    <frame>
      <level>1</level>
      <addr>0x080484f5</addr>
      <func>main</func>
      <file>test.c</file>
      <line>54</line>
    </frame>
  </stack>

4. A GDB/XMI Example
  
  4.1 The Inferior's Code
  #include <stdio.h>
  int main(int argc, char **argv){
    printf ( "newline\n" e;
    printf ( "nonewline" );
    return 0;
  }

  4.2 GDB/MI Output
    (gdb)
    -exec-run
    ^running
    (gdb)
    newline
    nonewline*stopped,reason="exited-normally"
    (gdb)

  4.3 GDB/XMI Output
  Assuming that the escape sequence is simply \027
  The whitespace is not necessary, and is simply there for presentation.

  \027<GDB_DISPLAY_PROMPT>
  (gdb) 
  </GDB_DISPLAY_PROMPT>\027
  \027<GDB_WAITING_FOR_COMMAND/>\027
  -exec-run
  \027<GDB_INFERIOR_STARTED/>\027
  newline
  nonewline\027<GDB_INFERIOR_FINISHED/>\027
  \027<GDB_DISPLAY_PROMPT>
  gdb
  </GDB_DISPLAY_PROMPT>\027
  \027<GDB_WAITING_FOR_COMMAND/>\027

  4.4 A Brief Description of the XMI output
  
    4.4.1 GDB_DISPLAY_PROMPT Document
    The front end receives the document below.
      \027<GDB_DISPLAY_PROMPT>
      (gdb) 
      </GDB_DISPLAY_PROMPT>\027
    The front end sends the data to the XML processor, which then tells
    it that the current prompt is "(gdb) ". The front end can choose to
    do whatever it wants with this information, including display it to the
    user, or just ignore it.

    4.4.2 GDB_WAITING_FOR_COMMAND Document
    Next, GDB transmits the document below.
      \027<GDB_WAITING_FOR_COMMAND/>\027
    The front end receives the data and sends it to the XML processor. The
    processor parses the document and the front end can determine that 
    the command says that GDB is ready to accept a user command. At this
    point, the front end understands that it is OK to transmit a command to
    GDB.

    4.4.3 The Front End Transmits a Command
    The front end transmits the command "-exec-run".
    Should the front end transmit commands in XML or just 
    ordinary text?

    4.4.4 GDB_INFERIOR_STARTED Document
    GDB would send a document telling the front end that the inferior
    has begun processing.
      \027<GDB_INFERIOR_STARTED/>\027
    Everything the front end processes from the pipe from this point 
    until the next GDB XMI Document transmission is from the inferior.
    It is considered to be output that the inferior would like to have
    the user see. The front end can process this data realtime, since
    it does not have to be sent to the XML parser for processing.

    The data
      newline
      nonewline
      is outputted by the inferior, and the front end processes this data
    realtime, understanding that it is not the output of GDB.

    4.4.5 GDB_INFERIOR_FINISHED Document
    GDB would send a document telling the front end that the inferior
    has finished processing.
      \027<GDB_INFERIOR_FINISHED/>\027

    This alerts the front end that GDB is now outputting XMI commands
    again. The front end no longer expects information from the inferior.
    Optionally, GDB could output a XMI command stating that a signal 
    has been caught, or some other asynchronous event has occurred. This
    could be something like
      \027<GDB_SIGNAL_CAUGHT>
      <SIGNAL>
        <NAME>SIGINT</NAME>
        <NUMBER>2</NUMBER>
        <COMMENT>Interrupt from keyboard</COMMENT>
      </SIGNAL>
      </GDB_SIGNAL_CAUGHT>\027
    In this way, GDB could alert the front end of any asynchronous event,
    and no special parsing mechanism will have to take place to 
    understand such actions.

5. Issues to resolve after RFC Initial approval.

  5.1 If GDB will link to libxml, or just output XML
    It would be nice if GDB was capable of sending the XML documents by
    creating them via libxml. However, libxml2 is licensed under the
    MIT license. Also, I don't know if libxml2 is as portable as GDB.

  5.2 How the schema will represent each document sent to the front end
    If there will be one schema for each XMI document, or a schema
    that represents every XMI document.

  5.3 Separating GDB output and the Inferior output 
    If GDB can output it's data on a different pipe than the 
    inferior then the escape sequences would not be needed to tell
    the front end which data is from GDB and which is from the inferior.

    This would simply the front end processing.

  5.4 If GDB recieves commands in XML
    If GDB links in libxml2, then it could easy receive commands from the
    front end in XML. This would be a nice feature, although, since the
    parser in GDB is only written once, it doesn't really matter what format 
    the commands are that is sent to it.