integrating GDB ? (was Re: Debugging with KDevelop)

[Francesco Montorsi]

Hi,

Andreas Pakulat wrote:
>>1) You cannot define any "expansion rule": I use everywhere wxString object 
>>types which
>>are the wxWidgets' strings. I just cannot see their contents unless I add as 
>>watch
>>expression: (char*)str.m_pchData, or unless I expand all the times the variable 
>>tree clicking on the variable until I reach the parent class and I can finally 
>>expand its m_pchData variable manually.
>>(also, when using Unicode, I cannot see string contents expanding the variables 
>>in the tree; probably because "wxChar" is mapped to "wchar_t" instead of 
>>"char"...).
>>
>>This is a big loss of time when you have to inspect many variables. In MSVC6 
>>there is the AUTOEXP.DAT file where you can define simple expansion rules. IMHO 
>>this feature would make the use of debugger 10/20 times faster.
> 
> 
> 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.

I made some researches in the WWW and I've found out a document which explains well my POV:
      http://sources.redhat.com/gdb/papers/libgdb2/libgdb.html

the first section says:

"[talking about GUI debuggers] Each of these debug GUI interfaces are implemented using an 
identical technique. GDB (or some other debugger) is started as a separate server process, 
debug commands are sent to that process and all output is then parsed. Of these, DDD is 
probably the most successful.

Unfortunately this technique has several limitations:

     * it is very sensitive to changes in GDB's output
     * performance is restricted by the speed of communication of between the GUI and GDB
     * it was difficult to keep the GUI consistent with the CLI "

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:
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
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 ?




>>2) You cannot see the return values of the functions. This is a bit problematic 
>>specially when the returned value is used directly in other expressions, 
>>without storing it in a variable...
> 
> 
> Hmm, MSVC6 does allow this? 
yes; it prints something like "foo() returned 'xyz'" into the "variables" window.


Francesco