Mirror of the gdb mailing list
 help / color / mirror / Atom feed
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



  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