I believe I see how to do this by construction a cbDebuggerPlugin object and populating some details, but that would require developing a C++ based plugin and getting it working under Windows (and MacOS) as well. Don't spend much timer on Windows, none on MacOS, so debugging this plugin would prove problematic.This won't work. cbDebuggerPlugin is an abstract class and instances are only available in the debugger plugins.
If there is no way to do this (currently) script-wize, are there suggestions as to desired ways to extend the Squirrel harness to accomplish this? I can do that myself, but don't want to step on toes if a roadmap intends to move things in a different direction in the future.
dbgObj=getDebugger("gdb");
dbgObj.setA(...);
dbgObj.setB(...);
etc.
Speaking of 'roadmap', is there an update somewhere as to plans? The latest one I find seems to stop at version 1.5.Nope, no one bothers to maintain it, because no one follows it.
I guess I could create a new plugin specifically for msp430, but as you say, it's only a standard GDB/CDB debugger object with a few settings changed. However, one BIG thing I want to change (unless someone points out an alternative) is adding the notion of a active 'server'. All of the embedded environments I've used that make any attempt to work with GDB, employ a custom 'server' to allow gdb to do it's stuff. This includes openOCD. In order to make this work in the C::B framework so far, I have to manually start the server before doing anything that attempts to use gdb. I've tried simply adding an invocation to the project/debugger options of shell commands to run before connection, but this fails much of the time (likely due to timing.) Further, some of these closed-source servers just die at random moments and the 'shell script' method doesn't know to re-start them. It's just painful.I use a delay command after the gdb server's launch command to make sure the server is initialized before gdb attempts to make a connection when I'm using AVRs on Windows. I also provided a patch here:
I use a delay command after the gdb server's launch command to make sure the server is initialized before gdb attempts to make a connection when I'm using AVRs on Windows. I also provided a patch here:
http://forums.codeblocks.org/index.php/topic,20272.0.html (http://forums.codeblocks.org/index.php/topic,20272.0.html)
to define custom debugger commands to be executed with one click (or shortcut) which you can use for restarting your server. Maybe these might help.
I have made my preliminary modifications but am having a philosophical argument with myself: I see that there are 'events' sent (specifically cbEVT_DEBUGGER_STARTED and cbEVT_DEBUGGER_FINISHED) from the debugger control harness. These would seem to be perfect for what's needed, but it would seem to require *yet another* plugin to accept them and there is still the issue of configuration for ONLY the MSP430 (or other server-based) debugger class of operation. My current mod is fairly delicate: it adds four configuration items to the debuggergdb 'plugin': an enable checkbox, a server path, an argument string and a 'run in separate window' checkbox (for debugging.) I then create a secondary GDB debugger with this stuff filled in so the 'main' local debugger doesn't use them. The debugger harness then starts and monitors the server thread *immediately before* starting the actual debugger, and fails of the server wll cause the debugger to 'restart' in as painless and transparent way as possible (TBD.) It's simple, but *does* tough the main gdb harness, though in a way that doesn't interfere with default operation.I'm not really sure this is a good idea, but I'm not sure there is something else to be done.
The alternative to this seems to be to create an entirely separate debuggergbd, duplicating nearly everything (except the CDB stuff) which seems overkill. Deriving from DebuggerGDB would possibly work, but it seems a bit clunky (at least to me.) Now I get that most people don't use the 'remote' debugging of GDB often, but it is such a simple extension, it feels like a straightforward mod to the DebuggerGDB is the easiest and cleanest way.This is a 100% no-go. There is a plan to replace the gdb with the gdb/mi debugger that is in the works. Also different debugger classes aren't designed to be derived.
...
I'm not really sure this is a good idea, but I'm not sure there is something else to be done.
I don't like it because it moves a complex machinery inside the plugin also it should be made cross platform and we should support it.
Probably we could try to add some events that allow a debugger plugin and a server launcher plugin to communicate.
But anyway post a patch we can discuss it further.