From: Bob Rossi <bob@brasko.net>
To: Joel Brobecker <brobecker@adacore.com>
Cc: "Jan Kratochvil" <jan.kratochvil@redhat.com>,
"Ömer Sinan Ağacan" <omeragacan@gmail.com>,
"Stan Shebs" <stanshebs@earthlink.net>, gdb <gdb@sourceware.org>
Subject: Re: GDB C API -- does such a thing exist?
Date: Fri, 17 Oct 2014 15:32:00 -0000 [thread overview]
Message-ID: <20141017153305.GA17782@linux> (raw)
In-Reply-To: <20141017122859.GA19237@adacore.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
next prev parent reply other threads:[~2014-10-17 15:32 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-16 11:21 Ömer Sinan Ağacan
2014-10-16 13:45 ` Phil Muldoon
2014-10-16 13:54 ` Joel Brobecker
2014-10-16 14:06 ` Jan Kratochvil
2014-10-28 12:58 ` Jonas Maebe
2014-10-16 14:01 ` Bob Rossi
2014-10-16 14:09 ` Jan Kratochvil
2014-10-16 23:45 ` Stan Shebs
2014-10-17 6:45 ` Ömer Sinan Ağacan
2014-10-17 8:08 ` Pedro Alves
2014-10-17 8:47 ` Pedro Alves
2014-10-28 13:30 ` Jonas Maebe
2014-10-30 10:09 ` Pedro Alves
2014-10-17 12:06 ` Jan Kratochvil
2014-10-17 12:29 ` Joel Brobecker
2014-10-17 15:32 ` Bob Rossi [this message]
2014-10-17 12:02 ` Jan Kratochvil
2014-10-17 12:17 ` Jan Kratochvil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141017153305.GA17782@linux \
--to=bob@brasko.net \
--cc=brobecker@adacore.com \
--cc=gdb@sourceware.org \
--cc=jan.kratochvil@redhat.com \
--cc=omeragacan@gmail.com \
--cc=stanshebs@earthlink.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).