On Fri, Oct 17, 2014 at 05:28:59AM -0700, Joel Brobecker wrote:
> > On Fri, 17 Oct 2014 14:02:50 +0200, Jan Kratochvil wrote:
> > # MI implements only very poor subset of GDB functionality
> > # so one has to use '-interpreter-exec console ...' anyway and parse the
> > # unparsable text output.
> > There is a theoretical suggestion that people should implement into
> > GDB anything they miss. But contributability to GDB is difficult for
> > many reasons besides that it is just an additional barrier to write an
> > MI client (when one has to write also the MI server along).
> My experience of contributing to GDB/MI does not match yours.
> When I worked with the IDE team at AdaCore on GDB/MI, they identified
> a number of missing failures, and implementation was both easy and
> contribution went well.
>From an outsider perspective, modifying GDB is clearly the right thing
to do, but adds additional barriers to the task at hand. It's difficult
and time consuming, and the changes won't be in the field for years to
Your AdaCore experience probably also coincided with a particular
release of GDB that you distributed. That's easy. You are fortunate.
For the rest of us attempting to deliver a front end to GDB, we have to
consider the version of GDB immaterial. It needs to work across all
variants or determine which features exist per GDB instance. This
is much more complicated. I'm still formulating a plan for this in gdbwire.
I envision the ideal front end client's philosophy as follows:
GDB is the core which produces 2) MI which is sent to 3) gdbwire which
produces events sent to 4) the front end.
Lets see how much of a reality I can make this.