how to use libgdb ?

how to use libgdb ?

[leiming]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 720 bytes --]


  hi!
  I¡¡want to build a GUI development enviroment ,in which I¡¡am considering to integrate the gdb debugger . The gdb internel  manual mentions the libgdb ,but the content seems a bit simple.
Who has used the libgdb and can give me a direction?
  Thanks a lot!

leiming
  
______________________________________

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

how to use libgdb ?

[leiming]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 621 bytes --]


  hi!
  Who has used libgdb to integrate gdb into GUI developement?
Can you tell me the detailed step or provide some manual?

  Thanks a lot!

leiming
<blackhorse_linux@sina.com>


______________________________________

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

Re: how to use libgdb ?

[Scott Moser]

Well,
   there really is no libgdb at this point.
   There has been some talk of one by developers as something they'd
eventually like to do, but right not there is nothing available.

   However, the gdb build process (at least on linux) created libgdb.a
and then builds main.c with that to create gdb.  It is possible to
create libgdb.so rather than libgdb.a and dynamically link to the new
library.  It just takes some fiddling with the Makefile that configure
created.
   I've not done extensive testing on it, but it seems to work for me.
If you wanted to build your own app on that, you could get sample usage
from the main.c file

   I guess it should be pointed out, though, that the libgdb.so that you
create is a GPL'd work, so even dynamically linking to it then requires
that you GPL your application as well.

Scott Moser
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-1533   T/L: 678-1533
ssmoser@us.ibm.com , internal zip: 9812

On Wed, 18 Sep 2002, leiming wrote:

>
>   hi!
>   Who has used libgdb to integrate gdb into GUI developement?
> Can you tell me the detailed step or provide some manual?
>
>   Thanks a lot!
>
> leiming
> <blackhorse_linux@sina.com>
>

Re: how to use libgdb ?

[Biswapesh Chattopadhyay]

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).

Plug: If you are on Linux, please try out Anjuta CVS - you can debug
Anjuta using Anjuta and the debugger interface is really nice !

Thanks in advance.
Biswa.


> Well,
> there really is no libgdb at this point.
> There has been some talk of one by developers as something they'd
> eventually like to do, but right not there is nothing available.
> 
>    However, the gdb build process (at least on linux) created libgdb.a
> and then builds main.c with that to create gdb.  It is possible to
> create libgdb.so rather than libgdb.a and dynamically link to the new
> library.  It just takes some fiddling with the Makefile that configure
> created.
>    I've not done extensive testing on it, but it seems to work for me.
> If you wanted to build your own app on that, you could get sample usage
> from the main.c file
> 
>    I guess it should be pointed out, though, that the libgdb.so that you
> create is a GPL'd work, so even dynamically linking to it then requires
> that you GPL your application as well.
> 
> Scott Moser
> Software Engineer; Linux Technology Center
> IBM Corp., Austin, Tx
> (512) 838-1533   T/L: 678-1533
> ssmoser@us.ibm.com , internal zip: 9812
> 
> On Wed, 18 Sep 2002, leiming wrote:
> 
> >
> >   hi!
> >   Who has used libgdb to integrate gdb into GUI developement?
> > Can you tell me the detailed step or provide some manual?
> >
> >   Thanks a lot!
> >
> > leiming
> > <blackhorse_linux@sina.com>
> >
> 
> 

Re: how to use libgdb ?

[Daniel Jacobowitz]

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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: how to use libgdb ?

[Scott Moser]

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.

Scott Moser
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-1533   T/L: 678-1533
ssmoser@us.ibm.com , internal zip: 9812

Re: how to use libgdb ?

[Daniel Jacobowitz]

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

Re: how to use libgdb ?

[Andrew Cagney]

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

Re: how to use libgdb ?

[Joel Brobecker]

> 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, ...

I totally agree. Also, one advantage of having your GUI and GDB as
separate processes is that you can then launch your GUI locally while
GDB is running on a distant machine. I do that fairly often with GVD,
with GVD running on my local machine in Vancouver, and the distant
machine being either in New York or Paris...

-- 
Joel