User forums > Embedded development
Is there a way to create a "Debug Target" using scripting?
Aerodesic:
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.
So, should I: 1) modify the 'standard' GDB debugger harness to allow this 'server' stuff (which is actually useful for more than just the Msp430) or 2) should I roll a separate (almost the same) plugin for this one specific case or 3) create a more generic 'server based' plugin for GDB (it needn't be CDB complient, after all?)
Just for the record: I *don't* want to actually *operate* the debugger from Squirrel; only configure it. I'm getting a better understanding of how this can be accomplished, but my concern is that I'm building something no-one (but me) will want. Is there an 'embedded' constituency for C::B that wants to tell me 'how they do it?'
scarphin:
--- Quote from: Aerodeisc on August 11, 2015, 12:58:57 am ---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.
--- End quote ---
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.
Aerodesic:
--- Quote from: scarphin on August 11, 2015, 08:18:25 am ---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.
--- End quote ---
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!)
oBFusCATed:
--- Quote from: Aerodeisc on August 11, 2015, 06:59:11 pm ---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.
--- End quote ---
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.
--- Quote from: Aerodeisc on August 11, 2015, 06:59:11 pm ---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.
--- End quote ---
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.
Aerodesic:
--- Quote from: oBFusCATed on August 11, 2015, 09:02:25 pm ---...
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.
--- End quote ---
So I can't derive from DebuggerGDB (and I *do* see why that would be a bad architecture, considering the plugin strategy) and separate debugger plugin doesn't work because I need to duplicate all of DebuggerGDB. "Rock and Hard Place" tm I could make a plugin that would listen for start/stop events, but don't see how I can get it integrated into the 'selected debugger' metaphore of the project. This field needs to define a *debugger*, not just a *plugin*. Trying not to sound 'snarky', but what was the vision on how this should be accomplished? [I suppose the correct answer might be: too many other fish in the pan frying... And that's an OK answer, really...]
So continuing on with my current path: adding a *small* amount of code to DebuggerGDB to handle the gdb notion of a 'server' and the mechanism to start/stop it. Admittedly a bit clunky since I've duplicated the LaunchProcess to create a LaunchServer (stripped much of it out.) Wanted to combine into one, but it got uglier looking - at least first attempt. It adds only a few members to the class object, but *does* needs some cross-communication, which will likely require some extra event handling. Currently I'm only looks for stdin/stdout, passing to Log and Terminate (which no only logs the fact, but *should* cause a restart and a message to the debugger process to re-establish communication - why this is necessary is due to a crappy (closed-source implementation of the server from TI/RedHat. It assumes you are running from a terminal and can manually restart things. Bleh.) Will provide auto restart before I submit patches.
Thanks for the feedback.
If you'd prefer me to take this offline to PM I can do that.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version