This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
RE: Re: how to use libgdb ?
- From: leiming <blackhorse_linux at sina dot com>
- To: Daniel Jacobowitz <drow at mvista dot com>
- Cc: Scott Moser <ssmoser at us dot ibm dot com>, Biswapesh Chattopadhyay <biswapesh_chatterjee at tcscal dot co dot in>, GDB List <gdb at sources dot redhat dot com>, Anjuta devel <anjuta-devel at lists dot sourceforge dot net>
- Date: Mon, 23 Sep 2002 10:48:28 +0800
- Subject: RE: Re: how to use libgdb ?
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)