Modifying the standard debugger plugin (gdb) for other debuggers?

[rickg22]

I'm currently testing the Python plugin and found a lot of ackward things. I then worried that for any new language some guy has to make his own incomplete and buggy debugger plugin.

My point is:

Shouldn't we extend the compiler/debugger plugin to make it support interpreted languages by default?

i.e. "This language is interpreted and don't need a compiler"
 [ ] Syntax Check command:

And for the debugger, telling it to debug the "main" source file instead of the "executable" (which doesn't exist, of course).

Additionally, the debugger could either have a list of debugger executables and their commands/return values syntax.

This way we could just drop in a "python/ruby/nice/whatever dataset for codeblocks debugger" instead of needing to write a "python/ruby/nice/whatever binary plugin".

What are the technical difficulties for this?

[dmoore]

In defense of my Python debugger, I spent 2 days writing it and haven't changed any of the core debugger code/ui since that time. That work was really just proof of concept. I learned two things writing that plugin: (1) getting the basic debugging operations working was straightforward, if a little tedious; (2) creating nice GUI elements (watches, stack etc) takes a lot of work (I cribbed some of them from the GDBDebugger plugin)

I'm obviously sympathetic to the idea that CB should be able to handle more than gdb, but I don't think extending the gdbdebugger plugin is the right way to go. For one, it would require all supported debuggers be command line tools for which it is possible to redirect I/O, which would miss out on debuggers that can be driven from an C++ API or some other means (e.g. RPC). A more general solution would be to expand the SDK to provide more support for debugging. The SDK could provide the resources common to all debuggers (breakpoints, toolbars, menu entries, watches, stack traces) and figure out which debugger should be called based on project/target settings.

[rickg22]

I'm obviously sympathetic to the idea that CB should be able to handle more than gdb, but I don't think extending the gdbdebugger plugin is the right way to go. For one, it would require all supported debuggers be command line tools for which it is possible to redirect I/O, which would miss out on debuggers that can be driven from an C++ API or some other means (e.g. RPC). A more general solution would be to expand the SDK to provide more support for debugging. The SDK could provide the resources common to all debuggers (breakpoints, toolbars, menu entries, watches, stack traces) and figure out which debugger should be called based on project/target settings.

But the debugger already handles command line debuggers - that's how gdb works, I think the process is straightforward: Making the plugin work not only with GDB, but with "GDB and friends"

If later there are other debuggers that work on a C++ API or RPC, we could make plugins specific to the debugger.

[dmoore]

I understand. My concern is that by making a "good enough" solution for commandline debuggers you won't make it any easier for someone who wants use non-commandline solutions. The gdb plugin doesn't really play nice with others. There's also a bunch of code in the gdb plugin that could be ported across to the SDK and made available to any debugger plugin. That will help to avoid the duplication of the gui interface for would-be debugger plugin writers and deal with the problem of sharing gui resources when more than one debugger plugin is present. Of course, that doesn't preclude proceeding with your solution in the short-term.