This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: MI: type prefixes for values
On Friday 17 February 2006 21:59, Eli Zaretskii wrote:
> > From: Vladimir Prus <ghost@cs.msu.su>
> > Date: Fri, 17 Feb 2006 17:24:03 +0300
> > Cc: gdb@sources.redhat.com
> >
> > > > - The parsing of that value will have to be done by ad-hoc code,
> > > > which is contrary to MI-goal of being easily parsable.
> > >
> > > Why ad-hoc? if you have {}, parse it, if not, don't. Why is this
> > > simple rule hard for a parser?
> >
> > Here's the relevant part from KDevelop:
> >
> > if (*start == '{')
> > {
> > // Gdb uses '{' in two cases:
> > // - composites (arrays and structures)
> > // - pointers to functions. In this case type is
> > // enclosed in "{}". Not sure why it's so, as
> > // when printing pointer, type is in parenthesis.
> > if (type == typePointer)
> > {
> > // Looks like type in braces at the beginning. Strip it.
> > start = skipDelim(start, '{', '}');
> > }
> > else
> > {
> > // Looks like composite, strip the braces and return.
> > return QCString(start+1, end - start -1);
> > }
>
> I'd never suspect that someone would try to parse MI with such
> ad-hoc'ish code. I assumed that a decent parser was being used, and
> that this parser could simply choose the right template--either the
> one for response with braces, or the one for without.
>
> With such one-character-at-a-time parsing of MI's output, I now
> understand why you want MI to talk in small chunks. This code is okay
> for parsing irregular streams such as what CLI produces, but that's not
> the right way of dealing with structured data streams such as the one
> produced by MI. You need a fairly general-purpose reader that would
> create a data structure for what it reads and populate the structure's
> members with what it finds in MI's output. Then you just pluck
> whatever you need from that data structure.
>
> I really don't think that we should cater to such ``parsers''. They
> need to be thrown away and rewritten, IMO.
Eli,
I'm disappointed by you making such broad statements based on no data.
Had you looked at code:
http://websvn.kde.org/branches/work/kdevelop-debugger-mi/mi/
http://websvn.kde.org/branches/work/kdevelop-debugger-mi/mi/gdbmi.h?rev=504799&view=markup
you'd notice that a data structure is being created. And as I've already said in this thread:
http://article.gmane.org/gmane.comp.gdb.devel/15652
the "breace-removing" code is specifically for removing uncessary data from "value" literals, which
have no formal grammar.
> > You see, if I strip everything {}-enclosed at the beginning of value,
> > I'll never show any structures. And how do I decide if the value is a
> > pointer, or structure?
>
> The same way a compiler's parser decides: by writing code that checks
> the text against several templates and finding the one that matches.
> I believe people who defined and implemented MI intended for its
> output to be structured so that it could be easily parsed, but you
> need to write a parser that knows how to deal with structured text.
> Take a look at an XML parser, for example, or at a Lisp reader.
Can you please avoid giving generic advice about writing parsers?
> That's how you should deal with this, IMO, not by looking at each
> individual character in turn and trying to decide, based on that
> single character, what could that mean.
I belive you're missing something. The *formal grammar*
of MI is actually LL(1), so it can be parsed exactly by looking
at one next character and deciding what to do.
> > > > > Then perhaps we should add the type info to all arguments, instead
> > > > > of removing it from where it exists now.the writers
> > > >
> > > > It might be good idea, but why don't add it as a separate field? I.e.
> > > > instead of
> > > >
> > > > ^done,value="(int *) 0x0"
> > > >
> > > > you'll get
> > > >
> > > > ^done,value="0x0",type="int *"
> > >
> > > Fine with me.
> >
> > So, are patches to the effect of removing type from value, and moving it
> > to a separate field welcome?
>
> I won't object. But I still think you need to replace that parser.
I think not.
- Volodya