GDB/MI how to go from the manual info to nuts and bolts...?

[Andrew Cagney]

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