hi!
  I want to build a small GUI development environment and I
am required to integrate GNU gdb into it. In the before discussions,
you mentioned the gdb/mi. I do want to know if gdb/mi can complete 
the task.Can you give me a hand?
  If this can do it,where may I find a more detailed related user 
manual for  the gdb manual is too simple?
  Thank you!

leiming         





----- Original Message -----
From:Daniel Jacobowitz <drow@mvista.com>
To:Scott Moser <ssmoser@us.ibm.com>
Subject:Re: how to use libgdb ?
Date:Fri, 20 Sep 2002 03:07:03 +0800
 >On Thu, Sep 19, 2002 at 11:00:37AM -0500, Scott Moser wrote:
 >> On Thu, 19 Sep 2002, Daniel Jacobowitz wrote:
 >> 
 >> > On Thu, Sep 19, 2002 at 09:38:40AM +0530, Biswapesh Chattopadhyay wrote:
 >> > > Hi list
 >> > >
 >> > > I'm one of the developers of Anjuta (http://anjuta.sf.net/), an IDE for
 >> > > GNOME. Currently, we are using a spawned subprocess for GDB interaction.
 >> > > This works fairly well, but obviously a shared library with a nice (and
 >> > > reasoinably stable) API would be very helpful for IDE developers. So, my
 >> > > question is: if GDB build process already builds libgdb.a, would any
 >> > > patches to make it build a shared libgdb.so be accepted into the main
 >> > > tree ? It might be very useful, for example, for gnome-debug, which is
 >> > > an upcoming component for debugging applications using a nice GUI
 >> > > interface. This might speed up the responsiveness and enable us to do
 >> > > more advanced stuff (such as tracing multiple threads simultaneously).
 >> >
 >> > They would probably not be accepted - or useful, since we don't plan to
 >> > maintain a stable ABI.  What we do maintain is a stable
 >> > machine-parseable interface - MI.  See the documentation or list
 >> > archives for more about that if you're not familiar with it.
 >> 
 >>    While its not my place to say whether or not the patches would be
 >> accepted, I do think they would be at least somewhat useful.
 >>    The ABI doesn't need to be stable right away, or even any time in the
 >> near future.  But it does seem like some people have an interest in
 >> seeing a libGDB in the short term and for sure in the long term.
 >>    I can think of many benefits to moving gdb to a small application
 >> that gains gets all its functionality from a library, but can't think of
 >> many cons.
 >>    pros:
 >>       allow other projects to use libgdb.so (while they know that it is
 >> not a stable backwards compatible ABI)
 >>       performance and functionality gains over the fork and pipe method
 >> for those apps.
 >>       through the use of libgdb.so by early adopters, learning what
 >> people would use it for, how they would use it... so that a better
 >> stable ABI *could* be made later.
 >>       allow plugins/extensions to gdb to be written in a much more cross
 >> platform manner.
 >> 
 >>    cons:
 >>       implied ABI stability.
 >> 
 >>    My feeling is that the pros outweigh the cons in this situation.  the
 >> implied ABI stability is only *implied*.  One suggestion to make sure no
 >> one thinks that you're implying it is would be to just printf inside _init() of
 >> that library with something like the following if the main executable
 >> isn't named gdb:
 >>    "This is not a stable ABI.  You probably shouldn't be using it unless
 >> you *really* know what you're doing.  And even then, maybe you shouldn't
 >> be using it.  Also, this code is GPL, if your application uses it, then
 >> it are bound to the terms of the GPL."
 >> 
 >>    What would it really hurt to have take this step now?  Please feel
 >> free add more negitive affects of doing this, maybe I'm just missing
 >> something.
 >
 >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.
 >
 >For plugins, the right thing to do is to _first_ define an ABI to
 >export to plugins, and then export it portably via (say) a table of
 >function pointers.
 >
 >-- 
 >Daniel Jacobowitz
 >MontaVista Software                         Debian GNU/Linux Developer
 >
 >

______________________________________

===================================================================
ÐÂÀËÃâ·Ñµç×ÓÓÊÏä (http://mail.sina.com.cn)
ÐÂÀ˶þÊÖÊг¡£ºÒ»ÔªÍ¶È룬ʮ·Ö¾ªÏ²£¬°Ù·ÖÂúÒâ (http://classad.sina.com.cn/2shou/)
ÊýÍòÕÅÊÖ»úͼƬÊýÍòÊ׶ÌÐÅÁåÉùÈÎÄãÌôÑ¡£¬Ã¿Ì춼ÓиüР(http://sms.sina.com.cn/cgi-bin/sms/smspic.cgi)