integrating GDB ? (was Re: Debugging with KDevelop)

[Vladimir Prus]

Hi Francesco,

> > kdevelop actually has no debugger of it's own, it's "only" a nice UI
> > around the gdb
>
> I think the problem of debuggers in Linux is that they all run GDB as a
> separate instance (with all communication problems that this comports)
> instead of using GDB as an external library and get direct access to its
> internals.

IMO, the main problem is insufficient quality of gdb itself. As example, for 
me it responds with "<incomplete type>" to the "print" command on a daily 
basis. It might be that gcc fails to produce some information for gdb, but I 
don't really care which exact code is wrong, as the net result is the same.

> I would underline the fact that this approach is slow: when I expand
> something or I want to inspect code in KDevelop's debugger view I see that
> KDevelop just asks everything to GDB and then parses its output. This is
> much slower than:

Do you have a concrete data for back up this statement?

> 1) link against a "libGDB"; the double quotes means: I know that GDB does
> not provide a library but it should be not too difficult to build one from
> the GDB's sources; I think that GDB programmers could add a target to their
> Makefile.in to build it, without too much work

Last time I asked about this in gdb mailing list, I go this reply from Daniel 
Jacobowitz:

 >> <aside>
 >> I might be wrong, but I feel it would be much better if gdb were a library 
 >> that I could link to. That would eliminate most anynchonious communication 
 >> and won't require to keep track which gdb reply corresponds to which 
 >> previously issued command and where the result of the command must be sent 
 >> inside the frontend.
 >> </aside>
 
 > I still think the MI communication model we've evolved is the best
 > choice.

The whole thread is http://sources.redhat.com/ml/gdb/2005-09/msg00032.html
Does not look like gdb developers are very keen about adding a target to their 
Makefile.in ;-)

> 2) call GDB's internal functions and "parse" their output; GDB is written
> in C and has a good interface (at least it seems since I'm looking at GDB
> sources for the first time). The main is simply:
>
> int
> main (int argc, char **argv)
> {
>    struct captured_main_args args;
>    memset (&args, 0, sizeof args);
>    args.argc = argc;
>    args.argv = argv;
>    args.use_windows = 0;
>    args.interpreter_p = INTERP_CONSOLE;
>    return gdb_main (&args);
> }
>
> and gdb_main() does the usual checks for options and then creates an
> "interpreter" instance and gives it the control...
> all user's command are probably given to the
>
> extern int interp_exec (struct interp *interp, const char *command);
>
> function; wouldn't be faster and better to use interp_exec() (and possibly
> other inner GDB functions) directly into KDevelop instead of relying on GDB
> output ?

I don't think why it's so. The output will be the same.

- Volodya