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
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.
Thanks for this. It is helpful, but doesn't completely solve my problem. Although it does allow restarting a dead server, there is still the fact that the 'deadness' isn't communicated to the application, and the user spends time waiting for the debugger to die (hitting the red X doesn't kill it immediately.) Restarting the server doesn't force the 'debugger' to reconnect, alas.
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.
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.
I am sensitive to what others may think, though (perhaps I should take this to Development thread) and admit I'm a noob with respect to the innards of C::B, though I do have quite a few years of C++ and other OO development experience. If there is a 'roadmap' even if it's in the heads of the core developers, I sure don't wish to push things the wrong way. I certainly don't need a 'quick fix' if there is a better, more reliable useful way to proceed.
For now, I will push on and when I'm finished, I'll submit some patches and y'all can decide if this is what works or not. In any case, I hope to contribute more to C::B down the road. It's a VERY useful tool for me and some of my associates. I've used it for 'real work' in several cases and it has been more reliable than just about *any* commercial tool (and I've used a bunch of them!)