GDB frontends, MI-speak and object notation

GDB frontends, MI-speak and object notation

[Dmitry Dzhus]

Hi all.

This summer I'm working on improvement for GDB Emacs frontend using
GDB/MI as a part of Google Summer of Code, and I'm looking for advice.

I wonder how other front-end developers handle GDB/MI output messages.
In the code I'm working on, regular expressions are used to parse MI
messages and extract certain values from them. This is pretty
straightforward to write, but doesn't seem to fully use the
«structuredness» of MI-speak, and lacks the spirit of MI. I'm reviewing
means of mapping MI (which seems to be a subset of JSON with a few
cosmetic differences and exceptions) to object-like structures so I can
work with it on a higher level. Has anyone had similar ideas?

I work with Lisp, so the mapping might be as follows:


    threads=[{id="1", target-id="LWP18334", frame={level="0",
    addr="0x08048b9a", func="mult_matrices_mt", args=[{name="m1",
    value="0x804ba30"}, {name="m2", value="0x804ba30"}], file="test.c",
    fullname="/home/sphinx/projects/gsoc/test.c", line="142"},
    state="stopped"}], current-thread-id="1"

to

    ((threads . (((id . "1")
                  (target-id . "LWP18334")
                  (frame . ((level . "0")
                            (addr . "0x08048b9a")
                            (func . "mult_matrices_mt")
                            (args . (((name . "m1")
                                      (value . "0x804ba30"))
                                     ((name . "m2")
                                      (value . "0x804ba30"))))
                            (file . "test.c")
                            (fullname . "/home/sphinx/projects/gsoc/test.c")
                            (line . "142")))
                  (state . "stopped"))))
     (current-thread-id . "1"))
-- 
Happy Hacking.

http://sphinx.net.ru
ã‚€

RE: GDB frontends, MI-speak and object notation

[Marc Khouzam]

 
> I wonder how other front-end developers handle GDB/MI output messages.
> In the code I'm working on, regular expressions are used to parse MI
> messages and extract certain values from them. This is pretty
> straightforward to write, but doesn't seem to fully use the
> <structuredness> of MI-speak, and lacks the spirit of MI. I'm 
> reviewing
> means of mapping MI (which seems to be a subset of JSON with a few
> cosmetic differences and exceptions) to object-like 
> structures so I can
> work with it on a higher level. Has anyone had similar ideas?

Yes, in Eclipse we parse the MI output into a hierarchy of classes
following the MI specification.  I agree with you that using
regular expression is loosing the value of MI.

I suggest you write a small parser that would extract
the hierarchical elements of the MI output and create a
structure you can access after.

I can point you to the java code of our parser if you'd like.

Marc

Re: GDB frontends, MI-speak and object notation

[André Pönitz]

On Thursday 28 May 2009 15:31:42 Marc Khouzam wrote:
> 
> > I wonder how other front-end developers handle GDB/MI output messages.
> > In the code I'm working on, regular expressions are used to parse MI
> > messages and extract certain values from them. This is pretty
> > straightforward to write, but doesn't seem to fully use the
> > <structuredness> of MI-speak, and lacks the spirit of MI. I'm 
> > reviewing
> > means of mapping MI (which seems to be a subset of JSON with a few
> > cosmetic differences and exceptions) to object-like 
> > structures so I can
> > work with it on a higher level. Has anyone had similar ideas?
> 
> Yes, in Eclipse we parse the MI output into a hierarchy of classes
> following the MI specification.  I agree with you that using
> regular expression is loosing the value of MI.

Same for Qt Creator. And I also think that regular expressions
is not a good long-term solution.

Andre'

Re: GDB frontends, MI-speak and object notation

[Dmitry Dzhus]

André Pönitz wrote:
> On Thursday 28 May 2009 15:31:42 Marc Khouzam wrote:
>> Yes, in Eclipse we parse the MI output into a hierarchy of classes
>> following the MI specification.  I agree with you that using
>> regular expression is loosing the value of MI.
>
> Same for Qt Creator. And I also think that regular expressions
> is not a good long-term solution.

Thanks for you feedback guys, that's just like I thought. I've started
hacking up a simple object mapper to use in my code.

>> I can point you to the java code of our parser if you'd like.

Please do.
-- 
Happy Hacking.

http://sphinx.net.ru
ã‚€

RE: Re: GDB frontends, MI-speak and object notation

[Marc Khouzam]

> >> I can point you to the java code of our parser if you'd like.
> 
> Please do.

You can do an anonymous check out the CDT code using a pserver 
connection from:
proxy.eclipse.org:80 under /cvsroot/tools

You should check out
org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb
then look for the file MIParser.java and the other
classes it uses.

Enjoy :-)

Marc

Re: GDB frontends, MI-speak and object notation

[Dmitry Dzhus]

I've managed to map MI output to structured data using JSON parser from
Emacs. I needed to wrap the whole GDB/MI answer in curly braces, wrap
«field names» in double quotes, and change equal signs in the
`VARIABLE=VALUE` pairs to semicolons. Using this approach I wrote rather
good-looking and good-working code to show information on threads in
Emacs.

That was a bit of a misplaced status report from me :) so I'll proceed to
some thoughts I had from my experience with GDB.

There is a dark corner in GDB/MI Output Syntax (section 26.2.2 of the
GDB manual) which doesn't fit to simple object model (for example, the
one JSON presents). This is the following case:

    `LIST ==>'
         ` "[" RESULT ( "," RESULT )* "]" '

It looks badly wicked and all broken to me to have things like this in
MI output (this is from `break-info`):

    body=[bkpt={number="1", … },bkpt={number="2", …}]

I feel that this should produce the following output instead:

    body=[{number="1", … },{number="2", …}]

`-stack-list-frames` is another command which uses this evil notation.

It is evil because it disallows thinking of tuples as objects and of
lists as, well, plain lists. This abuses the notion of a list! Moreover,
this makes TUPLEs *redundant* parts of GDB/MI, as they turn out to be a
subset of LISTs with curly braces instead of square brackets.

I wonder why was GDB/MI syntax designed this way. I believe it ought to
be changed (that would be backwards-incompatible, though, and a lot of
front-ends would get broken).

The other question is, why not use JSON in GDB/MI at all? Look like
there are no such cases where GDB/MI information cannot be successfully
expressed with JSON. Utilizing that would lower costs of production for
various GDB front-ends because there would be no need to maintain extra
parser for MI instead of using JSON parser which can also be used in a
number of other applications.

Comments from MI developers are welcome!
-- 
Happy Hacking.

http://sphinx.net.ru
ã‚€

Re: GDB frontends, MI-speak and object notation

[Vladimir Prus]

Dmitry Dzhus wrote:

> I've managed to map MI output to structured data using JSON parser from
> Emacs. I needed to wrap the whole GDB/MI answer in curly braces, wrap
> «field names» in double quotes, and change equal signs in the
> `VARIABLE=VALUE` pairs to semicolons. Using this approach I wrote rather
> good-looking and good-working code to show information on threads in
> Emacs.
> 
> That was a bit of a misplaced status report from me :) so I'll proceed to
> some thoughts I had from my experience with GDB.
> 
> There is a dark corner in GDB/MI Output Syntax (section 26.2.2 of the
> GDB manual) which doesn't fit to simple object model (for example, the
> one JSON presents). This is the following case:
> 
>     `LIST ==>'
>          ` "[" RESULT ( "," RESULT )* "]" '
> 
> It looks badly wicked and all broken to me to have things like this in
> MI output (this is from `break-info`):
> 
>     body=[bkpt={number="1", … },bkpt={number="2", …}]
> 
> I feel that this should produce the following output instead:
> 
>     body=[{number="1", … },{number="2", …}]
> 
> `-stack-list-frames` is another command which uses this evil notation.
> 
> It is evil because it disallows thinking of tuples as objects and of
> lists as, well, plain lists. This abuses the notion of a list! Moreover,
> this makes TUPLEs *redundant* parts of GDB/MI, as they turn out to be a
> subset of LISTs with curly braces instead of square brackets.
> 
> I wonder why was GDB/MI syntax designed this way. 

What makes you think it was designed? GDB/MI is not result of a design
session, but of somewhat long evolution, so some early decisions are
prominent.

> I believe it ought to 
> be changed (that would be backwards-incompatible, though, and a lot of
> front-ends would get broken).

So, that's only MI 3.0, in as yet unscheduled future.

> The other question is, why not use JSON in GDB/MI at all? Look like
> there are no such cases where GDB/MI information cannot be successfully
> expressed with JSON. Utilizing that would lower costs of production for
> various GDB front-ends because there would be no need to maintain extra
> parser for MI instead of using JSON parser which can also be used in a
> number of other applications.

I am unsure about this point. GDB/MI parsers to exist and can be reused
by interested parties easily. Changing format to accommodate new frontend
at expense of existing frontends does not seem good idea.

- Volodya

Re: GDB frontends, MI-speak and object notation

[Tom Tromey]

>>>>> "Dmitry" == Dmitry Dzhus <dima@sphinx.net.ru> writes:

Dmitry> I've managed to map MI output to structured data using JSON
Dmitry> parser from Emacs.

Fun approach... but I would recommend simply writing a true MI parser.
I think there are some elisp parser generators you could use.

Dmitry> The other question is, why not use JSON in GDB/MI at all?

JSON didn't exist when MI was written :).
But yeah, XML or even sexprs would have been a better choice, IMNSHO.
However, that is water under the bridge now... there are a dozen
working parsers, and I think breaking those should not be done
lightly, or perhaps at all.

BTW there are also known MI bugs in gdb, e.g.:

    http://sourceware.org/bugzilla/show_bug.cgi?id=9659

There was a discussion about this one on the list; I think the short
answer is that MI consumers just have to work around the broken bits.
(I think it would be nice if we could enumerate such cases in the
manual, so that MI users don't have to keep rediscovering this stuff,
but I am not sufficiently aware of all the oddities myself to do
this.)

Tom