From: Andrew Cagney <ac131313@ges.redhat.com>
To: Daniel Jacobowitz <drow@mvista.com>,
Scott Moser <ssmoser@us.ibm.com>,
Biswapesh Chattopadhyay <biswapesh_chatterjee@tcscal.co.in>
Cc: GDB List <gdb@sources.redhat.com>,
leiming <blackhorse_linux@sina.com>,
Anjuta devel <anjuta-devel@lists.sourceforge.net>
Subject: Re: how to use libgdb ?
Date: Thu, 19 Sep 2002 13:48:00 -0000 [thread overview]
Message-ID: <3D8A3811.5040502@ges.redhat.com> (raw)
In-Reply-To: <20020919190703.GA1494@nevyn.them.org>
For a background see:
http://sources.redhat.com/gdb/papers/libgdb2/
http://sources.redhat.com/gdb/papers/libgdb
(I've also added, slightly edited, one of the more legendary Cygnus
Internal white papers which is where MI came from.)
> The point is that there will never be a stable ABI. Speaking just for
> myself, I don't want a hack like this that we can never support. We
> have a machine interface - MI - and it should give you everything you
> need; if you think communication with GDB has any performance
> implications, you need to think about it a little more. If you think
> there are functionality gains from bypassing MI then MI should be
> extended.
Yes.
Given that Apple has proven that MI can be made to work, I don't see
benefit in adding (and hence implicitly supporting) yet another
interface. Remember, MI is documented and *tested*, you'll not get that
with some sort of internal ABI.
It is also very important keep in mind that directly linking GDB to an
application is not some sort of performance silver bullet. It isn't.
Too many other factors influence GDB/GUI performance - screen refresh
overhead, target step performance, cost of a stack unwind, even system
load, ...
Having said this, there is a very long term goal of implementing all MI
and CLI commands using functions of the form gdb_<mi-command-name>().
That, however, is very very long term (finished around '10?). At
present there are to many internal architectural problems to address.
Andrew
next prev parent reply other threads:[~2002-09-19 20:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-17 18:06 leiming
2002-09-18 9:29 ` Scott Moser
2002-09-18 21:08 ` Biswapesh Chattopadhyay
2002-09-19 6:32 ` Daniel Jacobowitz
2002-09-19 9:02 ` Scott Moser
2002-09-19 12:07 ` Daniel Jacobowitz
2002-09-19 13:48 ` Andrew Cagney [this message]
2002-09-19 14:18 ` Joel Brobecker
2002-09-18 18:02 leiming
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=3D8A3811.5040502@ges.redhat.com \
--to=ac131313@ges.redhat.com \
--cc=anjuta-devel@lists.sourceforge.net \
--cc=biswapesh_chatterjee@tcscal.co.in \
--cc=blackhorse_linux@sina.com \
--cc=drow@mvista.com \
--cc=gdb@sources.redhat.com \
--cc=ssmoser@us.ibm.com \
/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