This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: GDB C API -- does such a thing exist?
- From: Bob Rossi <bob at brasko dot net>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: Jan Kratochvil <jan dot kratochvil at redhat dot com>, Ãmer Sinan AÄacan <omeragacan at gmail dot com>, Stan Shebs <stanshebs at earthlink dot net>, gdb <gdb at sourceware dot org>
- Date: Fri, 17 Oct 2014 11:33:05 -0400
- Subject: Re: GDB C API -- does such a thing exist?
- Authentication-results: sourceware.org; auth=none
- References: <CAMQQO3=gR_6=D__Q_rn2Q8LQmE+bdokhAmbKh6fEkkNMH42fxA at mail dot gmail dot com> <5440588D dot 8060503 at earthlink dot net> <CAMQQO3nWoGCjgQOdzhR5U53pb-PjaZ+eJJaqghkNW62phMjbew at mail dot gmail dot com> <20141017120555 dot GC7123 at host2 dot jankratochvil dot net> <20141017122859 dot GA19237 at adacore dot com>
On Fri, Oct 17, 2014 at 05:28:59AM -0700, Joel Brobecker wrote:
> Jan,
>
> > 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
come.
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.
Thanks,
Bob Rossi