GDB MI Interface

Hi all,

I want to use the GDB MI interface to communicate with gdb
in the
backend of my software. Surprisingly, the current
information on this
topic is very less on the web. So I thought of turning to
the gdb
community itself. I had the following questions to ask -

1. Does the parser for MI output already exists ?
2. Are there some frontends debugger that are using this ?
As far as I
know, the ddd and kdb both use the CLI option.
3. Has there been any documentation on how to use gdb-MI.
The current
documentation is, as they say, like a reference manual.

Thanks in advance,

-Lokesh

-- 
"Doubt is not a pleasant condition, but certainty is
absurd."

Lokesh krishna

Lokesh krishna wrote:
> Hi all,
>
> I want to use the GDB MI interface to communicate with
gdb in the
> backend of my software. Surprisingly, the current
information on this
> topic is very less on the web. So I thought of turning
to the gdb
> community itself. I had the following questions to ask
-
>
> 1. Does the parser for MI output already exists ?
>   

No. You need to write your own.


> 2. Are there some frontends debugger that are using
this ? As far as I
> know, the ddd and kdb both use the CLI option.
>   

The NetBeans C/C++ gdb module uses gdb/mi.


> 3. Has there been any documentation on how to use
gdb-MI. The current
> documentation is, as they say, like a reference
manual.
>   

Chapter 25 of the gdb manual 
(http://sourceware.org/gdb/current/onlinedocs/gdb_25.html
)
describes the interface.

Gordon

> Thanks in advance,
>
> -Lokesh
>
>   

On Friday 11 April 2008 02:07:15 Lokesh krishna wrote:
> Hi all,

Hi Lokesh.

> I want to use the GDB MI interface to communicate with
gdb in the
> backend of my software. Surprisingly, the current
information on this
> topic is very less on the web. So I thought of turning
to the gdb
> community itself. I had the following questions to ask
-
> 
> 1. Does the parser for MI output already exists ?

I am not aware of an "official" MI parser. I am
using a home grown one
which is ~260 lines of straight-forward C++, It's probably
not complete,
but reads the parts I am interested in sufficiently well


> 2. Are there some frontends debugger that are using
this ? As far as I
> know, the ddd and kdb both use the CLI option.

See Vladimir's posting 

Apart from that I am trying to use MI as it relays
structured data much better
then the CLI. The two main problems with gdb/MI is that it
is (a) incomplete, 
so there are lots of "traditional" commands that
do not have an MI equivalent
or whose MI equivalent just chickens out saying "not
implemented", and
(b) that it seems to be a constant flux.

It's a bit of a trade-off. _Not_ using MI would give an
imaginary frontend
the possibility to use Intel's debugger, too, as this can be
configured
to look pretty much like the gdb CLI.

> 3. Has there been any documentation on how to use
gdb-MI. The current
> documentation is, as they say, like a reference
manual.

Chapter 24 in the docs found on

 http://sourceware.org/gdb/current/onlinedocs/gdb_toc.ht
ml

is usable. The problem is that there are different flavours
of MI out in
the wild, and point (b) above leading to the necessity to
double-check
anything written in the docs with the actual gdb
incarnations you want to
support - which is a wee bit less convienient than you could
dream of
in a perfect world 

Regards,
Andre'

Hi,

I think I found what I was looking for. Sharing it here for
others as well.

On Fri, Apr 11, 2008 at 8:07 AM, Gordon Prieur
<Gordon.Prieursun.com> wrote:
>
>  Lokesh krishna wrote:
>
> > Hi all,
> >
> > I want to use the GDB MI interface to communicate
with gdb in the
> > backend of my software. Surprisingly, the current
information on this
> > topic is very less on the web. So I thought of
turning to the gdb
> > community itself. I had the following questions to
ask -
> >
> > 1. Does the parser for MI output already exists ?
> >
> >
>
>  No. You need to write your own.

http://sour
ceforge.net/projects/libmigdb/

This library provides all the function that one may need to
start gdb,
interact with it (seeting breakpoints, watchpoints, run,
stop, step
etc.) and parse the output. A good tool for someone planning
to use
GDB MI.
>
>
>
>
> > 2. Are there some frontends debugger that are
using this ? As far as I
> > know, the ddd and kdb both use the CLI option.
> >
> >
>
>  The NetBeans C/C++ gdb module uses gdb/mi.
>
>
>
>
> > 3. Has there been any documentation on how to use
gdb-MI. The current
> > documentation is, as they say, like a reference
manual.
> >
> >
>
>  Chapter 25 of the gdb manual
> (http://sourceware.org/gdb/current/onlinedocs/gdb_25.html
)
>  describes the interface.
>
>  Gordon
>
>
> > Thanks in advance,
> >
> > -Lokesh
> >
> >
> >
>



-- 
"Doubt is not a pleasant condition, but certainty is
absurd."

Lokesh krishna

Mobile: +1 917 319 0360

 > http://sour
ceforge.net/projects/libmigdb/
 > 
 > This library provides all the function that one may
need to start gdb,
 > interact with it (seeting breakpoints, watchpoints,
run, stop, step
 > etc.) and parse the output. A good tool for someone
planning to use
 > GDB MI.

It appears that the last release was 2004-07-20 and that
there is no mailing
list.  I don't recall the author being active on this list. 
MI is still
evolving so I suggest that if you are are going to use this
library that you
follow events here and share your experiences.

-- 
Nick                                           http://www.inet.net.n
z/~nickrob

On Sun, Apr 13, 2008 at 02:41:10PM -0700, Lokesh krishna
wrote:
> Hi,
> 
> I think I found what I was looking for. Sharing it here
for others as well.

You could start by looking at,
  http://cgdb.svn.sourceforge.net/viewvc/cgdb/cgd
b/trunk/lib/gdbmi/
It is _not_ currently an implementation that works. However,
it does use
the push parser feature of bison that is just about to be
released. This
allows the generated parser to be used asynchronously. I
think I'm going
to have time to finish this library this year, but I can't
promise.

Bob Rossi

On Sun, Apr 13, 2008 at 3:05 PM, Nick Roberts
<nickrobsnap.net.nz> wrote:
>  > http://sour
ceforge.net/projects/libmigdb/
>   >
>   > This library provides all the function that one
may need to start gdb,
>   > interact with it (seeting breakpoints,
watchpoints, run, stop, step
>   > etc.) and parse the output. A good tool for
someone planning to use
>   > GDB MI.
>
>  It appears that the last release was 2004-07-20 and
that there is no mailing
>  list.  I don't recall the author being active on this
list.  MI is still
>  evolving so I suggest that if you are are going to use
this library that you
>  follow events here and share your experiences.

I wonder if it would be useful to add something like this to
the GDB
tree.  Maybe not this specific implementation, but something
with the
same purpose.  Put a python wrapper on it and ... cool. 
OTOH, it'd be
sort of like the new python scripting support but inverted
(python
<--> gdb instead of gdb <--> python, if that
makes any sense).

Is it lamentable that we have both gdbmi and (soon) a real
scripting
interface with no real commonality?  Just thinking out loud
... I
don't have an answer.

>>>>> "Doug" == Doug Evans
<djegoogle.com> writes:

Doug> Is it lamentable that we have both gdbmi and (soon)
a real scripting
Doug> interface with no real commonality?  Just thinking
out loud ... I
Doug> don't have an answer.

I worried about this a bit, particularly when hacking up the
event
code to be able to notify python even when some other
interpreter has
been chosen.

Now I think the two things are orthogonal.

You need something like MI so that UIs, even text-y ones
like Emacs,
can drive gdb intelligently.

But, for folks using the CLI, you need better scripting than
what has
historically been provided.  I suppose in theory this could
be
provided by whatever is driving MI -- but perhaps at the
cost of
having to rewrite app-specific gdb scripts once per UI.

Tom

On Tue, Apr 15, 2008 at 01:46:28PM -0700, Doug Evans wrote:
> Is it lamentable that we have both gdbmi and (soon) a
real scripting
> interface with no real commonality?  Just thinking out
loud ... I
> don't have an answer.

I don't think it is.  My limited implementation experience
with trying
to exploit commonality found the scripting interface too
cumbersome.

-- 
Daniel Jacobowitz
CodeSourcery