This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: GDB/MI how to go from the manual info to nuts and bolts...?
- To: Brian <bvstraalen at lbl dot gov>
- Subject: Re: GDB/MI how to go from the manual info to nuts and bolts...?
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Mon, 23 Oct 2000 13:56:02 +1100
- Cc: gdb at sources dot redhat dot com
- References: <39F27F9B.E8AD2F36@lbl.gov>
Brian wrote:
>
> I've had a read through ot the GDB MI interface manual section , but I
> still
> can't figure out what is going on. There had been talk that this was an
> attempt
> to do what libGDB was supposed to do. So does GDB MI build a library
> you can link into your application code ? I've been wanting to have
> stack
> trace dump and maybe CLI invocation from a compiled program on error
> signals and abort
> calls. How does the MI make it possible to make gdb part of a larger
> application ?
MI gives GDB a well behaved (and extreemly predictable) textual
interface. Up until now people have done things like:
DDD <-> GDB/CLI + GDB core
MI changes that to a much more tightly defined:
GUI <-> GDB/MI + GDB core
within MI there is the UI-OUT object. You've several choices:
o use MI and GDB as a separate
process.
If your GUI is scripting language
based then this is probably the best
move. If you combine GDB and
the script interpreter in a single
executable then a GDB bug (what never!)
easily crash your larger application.
I believe that this is part of
what the SourceNav people
want to do.
o use the layer below MI and link
in your application directly.
A variation on this is to use the
layer below MI to build an interface
that is specific to your separate
GUI application.
I believe this is the other half of
what the SourceNav people want to do.
(add a tcl specific equivalent to the MI layer
so that GDB<->SN comms is more efficient.)
Right now, MI development is waiting for a ``customer'' (a GUI wanting
to use it and drive it further.)
Andrew