From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: gdb@sourceware.cygnus.com Subject: Re: Library interface to GDB Date: Thu, 27 May 1999 23:03:00 -0000 Message-id: <374E319F.54921BD7@cygnus.com> References: <86k8tu9pyj.fsf@localhost.uni-trier.de> X-SW-Source: 1999-q2/msg00124.html Martin Baulig wrote: > > The gdb source code (4.18) contains a file gdb/doc/libgdb.texi which has > been last modified in November 1993. This libgdb ist last mentioned in the > ChangeLogs in 1994/95. In the internals manual I finally found a note that > this "project" was aborted. On the other hand, I still find some references > to it at least the Makefile.in, but I remember having seen something about > it in the code itself. Yes, if you look carefully at the code you'll probably notice many things that have been structured in strange or mysterious ways. I just deleted several of them (the functions in question were empty): Tue May 25 15:20:58 1999 Andrew Cagney * main.c (init_proc, proc_remove_foreign): Delete function. * inftarg.c (child_mourn_inferior): Update. Delete call to proc_remove_foreign(). * top.c (gdb_init): Update. Delete call to init_proc(). My understanding (third hand?) is that at the time (back in '94/95) libgdb proved to be one of those `good ideas'. The sort of thing that sounds good after one too many drinks :-) What did come from it, though, was a number of goals that would allow GDB to evolve into a more powerful architecture better suited for things like GUI's. To give a real example: Elena, Stan (and many others) have just released the re-worked GDB that includes an event loop (it is often referred to as async). An event loop is the sort of basic infrastructure needed in a debugger if it is ever going to function correctly within a GUI or be embedded in a library. Without it, when blocked waiting for a target, the debugger _IGNORES_ all other input sources (such as its CORBA interface). As a testament to the quality of this work, it was completed in a way that allows GDB to continue to function on all the existing host-X-target combinations. It would be interesting to know how many of the ``libgdb'' implementations people have so far put forward actually addressed this fairly fundamental technical issue. > What is the current status for libgdb, is it still supported or already > removed or whatever ... ? That project, as you note, was aborted long ago. Many people have, however, set out and achieved similar goals with varying degrees of success. > Basically I want to write a GNOME frontend for gdb, but not just > "yet another gdb frontend", but *the* gdb frontend. Ideally it should > export all its functionallity through CORBA so you can also use it in > other projects like GNU Emacs, KDE or whatever. With respect to CORBA, I see that one person mentioned that they had implemented an interface by coding a parser of GDB's output. To me, this sounds like taking things in the wrong direction. It is the sort of solution used when talking to an unchanging legacy system. GDB, while old, is neither un-changing nor legacy :-) GDB's CLI is definitely going to continue to evolve. If there is going to an interface added to GDB then I think that it should be implemented in a way that lends its self to maintainability over a longer time frame. While a CORBA interface is flavor of the month, I believe that other people have different (although potentially related) ideas. RMS, for instance, has pointed out that GDB should have an interface that allowed scheme/guile to be integrated (as the official scripting language). (I like others have further thoughts on this but this e-mail is a big enough chunk for now :-) enjoy, Andrew >From ac131313@cygnus.com Fri May 28 00:28:00 1999 From: Andrew Cagney To: gdb@sourceware.cygnus.com Subject: Re: GDB meeting, Silicon Valley 1999-05-14 Date: Fri, 28 May 1999 00:28:00 -0000 Message-id: <374E4596.46F09793@cygnus.com> References: <199905110256.TAA08098@andros.cygnus.com> X-SW-Source: 1999-q2/msg00125.html Content-length: 1704 Stan Shebs wrote: > If you can't make it, I expect that we will post a > summary of the meeting afterwards. Stan is away on holidays. I thought I posted the below several days ago, but unfortunately, it is now looking like it didn't go out :-( The below was drafted by Stan. I've since edited it slightly and am now posting it. sorry for the delay, Andrew -- Last Friday (1999-05-14) a group of GDB hackers and other interested parties got together to discuss the maintenance of GDB. The meeting was held at HP's Cupertino CA campus, and included the following participants: Andrew Cagney (cagney@cygnus.com) J. T. Conklin (jtc@redbacknetworks.com) Robert Dewar (dewar@gnat.com) Klee Dienes (klee@apple.com) Wes Embry (wes@sgi.com) Paul Hilfinger (hilfingr@CS.Berkeley.edu) David Metcalfe (crdjm@sgi.com) Paul Sanville (sanville@flytrap.cup.hp.com) Stan Shebs (shebs@cygnus.com) Richard Stallman (rms@gnu.org) Mike Vermeulen (mev@cup.hp.com) Sanjay Waghray (sw@home.com) Todd Whitesel (toddpw@wrs.com) Much of the discussion focussed on the technical directions that have been discussed in this forum already (multi-architecture, multi-process, async debug). There was also discussion of using Guile with GTK to build the standard windowed interface for GDB. We did agree to form a "steering committee" for GDB. This committee (having a size and form similar to the existing GCC committee) would focus on overall policy for GDB. Day-to-day maintenance issues would generally continue as before. Committee membership was not decided at this meeting, and will be worked out in the coming weeks. -- >From martin@home-of-linux.org Fri May 28 01:32:00 1999 From: Martin Baulig To: Andrew Cagney Cc: gdb@sourceware.cygnus.com Subject: Re: Library interface to GDB Date: Fri, 28 May 1999 01:32:00 -0000 Message-id: <86hfoxegy4.fsf@localhost.uni-trier.de> References: <86k8tu9pyj.fsf@localhost.uni-trier.de> <374E319F.54921BD7@cygnus.com> X-SW-Source: 1999-q2/msg00126.html Content-length: 902 Andrew Cagney writes: > If there is going to an interface added to GDB then I think that it > should be implemented in a way that lends its self to maintainability > over a longer time frame. While a CORBA interface is flavor of the > month, I believe that other people have different (although potentially > related) ideas. RMS, for instance, has pointed out that GDB should have > an interface that allowed scheme/guile to be integrated (as the official > scripting language). Yes, I agree. It's nice to have a CORBA interface for gdb, but that should be separeted from the actual gdb distribution - this can for instance be handled by applications like dryad. However, a guile interface really sounds good - especially since this is the official scripting language. Maybe I can give it a try ... -- Martin Baulig - martin@home-of-linux.org - http://www.home-of-linux.org >From jkamdar@emc.com Fri May 28 07:38:00 1999 From: Jayesh Kamdar To: Martin Baulig Cc: Andrew Cagney , gdb@sourceware.cygnus.com Subject: Re: Library interface to GDB Date: Fri, 28 May 1999 07:38:00 -0000 Message-id: <374EAA39.FCBEBB58@emc.com> References: <86k8tu9pyj.fsf@localhost.uni-trier.de> <374E319F.54921BD7@cygnus.com> <86hfoxegy4.fsf@localhost.uni-trier.de> X-SW-Source: 1999-q2/msg00127.html Content-length: 1547 Sorry for the ignorance ( I am not a developer) but is COBRA an GUI interface to GDB ? Is it available on all platforms ? And where can I get it from ? And also, then what is xxgdb, isn't it a GUI gdb ? Thanks, Jayesh Martin Baulig wrote: > > Andrew Cagney writes: > > > If there is going to an interface added to GDB then I think that it > > should be implemented in a way that lends its self to maintainability > > over a longer time frame. While a CORBA interface is flavor of the > > month, I believe that other people have different (although potentially > > related) ideas. RMS, for instance, has pointed out that GDB should have > > an interface that allowed scheme/guile to be integrated (as the official > > scripting language). > > Yes, I agree. It's nice to have a CORBA interface for gdb, but that should > be separeted from the actual gdb distribution - this can for instance be > handled by applications like dryad. > > However, a guile interface really sounds good - especially since this is > the official scripting language. Maybe I can give it a try ... > > -- > Martin Baulig - martin@home-of-linux.org - http://www.home-of-linux.org -- _________________________________________________________ Contrary to popular belief, UNIX is user friendly. It's just very particular about who it makes friends with _________________________________________________________ Jayesh Kamdar (Email: jkamdar@emc.com) EMC Corp. 171 South St., Hopkinton, MA 01748 Ph.: 800-445-2588 x2464 Fax: 508-435-8824 >From ovidiu@cup.hp.com Fri May 28 09:04:00 1999 From: Ovidiu Predescu To: Martin Baulig Cc: Andrew Cagney , gdb@sourceware.cygnus.com Subject: Re: Library interface to GDB Date: Fri, 28 May 1999 09:04:00 -0000 Message-id: <199905281604.JAA12819@hpcll563.cup.hp.com> References: <86hfoxegy4.fsf@localhost.uni-trier.de> X-SW-Source: 1999-q2/msg00128.html Content-length: 2866 On 28 May 1999 10:28:35 +0200, Martin Baulig wrote: > Andrew Cagney writes: > > > If there is going to an interface added to GDB then I think that it > > should be implemented in a way that lends its self to maintainability > > over a longer time frame. While a CORBA interface is flavor of the > > month, I believe that other people have different (although potentially > > related) ideas. RMS, for instance, has pointed out that GDB should have > > an interface that allowed scheme/guile to be integrated (as the official > > scripting language). > > Yes, I agree. It's nice to have a CORBA interface for gdb, but that should > be separeted from the actual gdb distribution - this can for instance be > handled by applications like dryad. > > However, a guile interface really sounds good - especially since this is > the official scripting language. Maybe I can give it a try ... IMO libgdb should provide more than a simple interface to the gdb commands. Ideally it should provide an object-oriented view of the GDB internal structures. All the GDB structures that are used internally by GDB, frames, symbols, values, breakpoints and so on, would become classes and would have methods that operate on them. If these objects are exported in a scripting language then writing extensions would be very easy, since you have access to GDB's internals. For example you could imagine an interface to the outside world that uses the HTTP protocol and returns the data in an XML format. You could relatively easy build a graphical user interface that's running in Netscape, just replace the output format of the data to use HTML instead of XML. Or you can write a Corba interface that exports these GDB objects or provides an API for building GUIs. In the WDB project ( http://www.hp.com/esy/lang/tools/Debuggers/WDB/index.html ) we are working on integrating Python into GDB and exporting the GDB structures as first class objects in it. Python ( http://www.python.org ) is an interpreted object-oriented language with very powerful capabilities and rich libraries. With this layer built on top of GDB, you can use a language bridge to export the Python objects into other languages like Guile or Perl. The Python objects would appear as native objects in these languages so you could send messages in a transparent way from Perl or Guile to an object whose implementation is written in Python. If the bridge is multi-directional, the other way are also possible, invoking Guile or Perl methods from Python. Such an idea is already implemented by the ILU project (see ftp://ftp.parc.xerox.com/pub/ilu/ilu.html ). This way we basically give our users the language of their choice to implement extensions. Greetings, -- Ovidiu Predescu http://www.geocities.com/SiliconValley/Monitor/7464/