From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stan Shebs To: martin@home-of-linux.org Cc: gdb@sourceware.cygnus.com Subject: Re: Library interface to GDB Date: Mon, 07 Jun 1999 17:13:00 -0000 Message-id: <199906080013.RAA11485@andros.cygnus.com> References: <86k8tu9pyj.fsf@localhost.uni-trier.de> X-SW-Source: 1999-q2/msg00141.html From: Martin Baulig Date: 27 May 1999 23:12:52 +0200 Hi, I'm just catching up with my mail. It looks like everything has been pretty well discussed already, so I'll throw in a couple extra points. 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. What is the current status for libgdb, is it still supported or already removed or whatever ... ? There were actually two projects that went on - one was Cygnus' first attempt to build a GUI (which failed to produce anything usable and was killed off), and then later Cygnus had a contract to enable GDB to work as a component of a fancy parallel debugging system. For both of these "libgdb" was a nice-to-have, not a requirement, so you ended up with the situation you see now, where things were started but not finished. So right now libgdb work is in limbo. Since I figured it would restart someday, I left the docs and other bits in, so people wouldn't have to reinvent any wheels. There seems to be a resurgence of interest in adding different kinds of frontends to GDB, so this seems like a good time to get moving on it again... 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. The GNU project would like to see somebody do the GDB + Guile + gtk + Gnome combination, so if you work on that, you will have people cheering you on. An internal GDB API ("libgdb") is not a base requirement for this, but to me is simply good software engineering - since you will end up with both a command-line interface and a compiled-in GUI, libgdb will be the result of factoring the code into interface and debugger subsystems. As for the design of the API, Ovidiu's message is a good discussion of a key point, namely, that the API should be object-oriented. Not in a literal sense, since there needs to be a plain C implementation of it, but logically, since GDB maintains large amounts of internal state, and a reasonable API would be expressed in terms of operations on the objects that make up that state. Stan >From shebs@cygnus.com Mon Jun 07 17:20:00 1999 From: Stan Shebs To: kettenis@wins.uva.nl Cc: gdb@sourceware.cygnus.com Subject: Re: Debugging dynamically linked executables Date: Mon, 07 Jun 1999 17:20:00 -0000 Message-id: <199906080020.RAA11496@andros.cygnus.com> References: <199905081445.QAA06947@delius.kettenis.nl> X-SW-Source: 1999-q2/msg00142.html Content-length: 895 Date: Sat, 8 May 1999 16:45:39 +0200 (CEST) From: Mark Kettenis AFAICT it is not possible to make gdb stop at the first instruction that will be executed for a dynamically linked executable (which will probably be the first instruction of the dynamic linker). [...] I was thinking about adding an option (suggested name stop-on-startup), so that people could say "set stop-on-startup 1". Would this be acceptable? I read this, and got a sense of deja' vu (not dejagnu :-) ) about having discussed this with Richard Henderson and Ulrich Drepper at some point, in connection with debugging dynamic loaders... In any case, the idea of a stop-on-startup option seems reasonable to me. Since it's not a normal user option, you would probably want to put it into the "obscure" class, perhaps even make it a maintenance command. Stan