From mboxrd@z Thu Jan 1 00:00:00 1970 From: Brendan Simon To: Stan Shebs Cc: gdb@sourceware.cygnus.com Subject: Re: Library interface to GDB Date: Mon, 07 Jun 1999 17:42:00 -0000 Message-id: <375C6594.289E0D94@dgs.monash.edu.au> References: <199906080013.RAA11485@andros.cygnus.com> X-SW-Source: 1999-q2/msg00143.html Stan Shebs wrote: > 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. How do other GUIs (DDD, VIDE, etc) currently interface with GDB ? Through a library interface (shared or static) ? Through operating system inter-process communications ? By faking user input command lines ? Some other means which is beyond my limited mind to think of ? I would have thougt that libgdb would be the obvious choice but if it has been in limbo for a while then there must be another method. Brendan Simon.