Code::Blocks

User forums => Embedded development => Topic started by: Aerodesic on August 09, 2015, 11:20:45 pm

Title: Is there a way to create a "Debug Target" using scripting?
Post by: Aerodesic on August 09, 2015, 11:20:45 pm
I'm working on a (script only) plug in for MSP430 using the TI supported tool set.  All is working except my need to manually create a GDB target to use msp43-elf-gdb.  I'd rather have this be automatically created when the plugin is run rather than manually setting up the target information.

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.

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.

Speaking of 'roadmap', is there an update somewhere as to plans?  The latest one I find seems to stop at version 1.5.

Thanks,
Gary
Title: Re: Is there a way to create a "Debug Target" using scripting?
Post by: oBFusCATed on August 10, 2015, 08:04:20 pm
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.

I don't think there an api at the moment to do this. Probably you can use the raw xml api, but I don't recommend this approach.
I don't think there is a plan this to be added, but if there is the api should be specific for the gdb/cdb plugin, so it should be implemented there and not in the sdk.
Probably the sdk should provide some common way to ask any debugger  plugin for its apis. Something like:
Code: [Select]
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.
Title: Re: Is there a way to create a "Debug Target" using scripting?
Post by: BlueHazzard on August 10, 2015, 10:49:13 pm
i don't understand to 100% what you want to do.
Create a debugger plugin, that handles break points etc for the msp43-elf-gdb? Do you only need to set the executable, and add some config stuff to the actual gdb debugger plugin?

Writing a debugger plugin is not that hard. You can look at the python debugger or the squirrel debugger for reference:
https://github.com/spillz/codeblocks-python/tree/master/PythonDebugger
and
https://github.com/bluehazzard/cbSquirrelDebugger

extending cbDebuggerPlugin with squirrel is possible, but tons of work, and i'm not 100% sure if it would be worth the work. To make things a bit more easy you would need c++11 but c::b does not use it so far...

greetings
Title: Re: Is there a way to create a "Debug Target" using scripting?
Post by: oBFusCATed on August 10, 2015, 11:36:39 pm
As far as I could understand he wants to write a script that can setup the remote debugging options for the gdb debugger.
Title: Re: Is there a way to create a "Debug Target" using scripting?
Post by: Aerodesic on August 11, 2015, 12:40:31 am
I'm trying to develop the plugin using the scripting mechanism only.  I realize I can create a 'proper' plugin the C++ way, but that would (eventually) require me to vet it for operation under (all versions) of Windows and MacOS.  Rather not, since I don't have development environments for those systems.  The *tools* are supported under those OSs but I don't have to do anything other than see to it they are called.

Seems the Squirrel environment *should* be up to this task (with the addition of some additional exported funtionality.)  I am aware that security issues may ensue with this mechanism, but it doubt it's anything more than what would happen if I did it the C++ way.  Any additional interfaces would need to be robust and secure against all script tweeks...
Title: Re: Is there a way to create a "Debug Target" using scripting?
Post by: Aerodesic 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.

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?'
Title: Re: Is there a way to create a "Debug Target" using scripting?
Post by: scarphin on August 11, 2015, 08:18:25 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.
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.
Title: Re: Is there a way to create a "Debug Target" using scripting?
Post by: Aerodesic on August 11, 2015, 06:59:11 pm
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.

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!)
Title: Re: Is there a way to create a "Debug Target" using scripting?
Post by: oBFusCATed on August 11, 2015, 09:02:25 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.
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.

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.
Title: Re: Is there a way to create a "Debug Target" using scripting?
Post by: Aerodesic on August 12, 2015, 08:02:10 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.

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.
Title: Re: Is there a way to create a "Debug Target" using scripting?
Post by: oBFusCATed on August 12, 2015, 08:48:43 pm
Post a patch when you have something that you're happy with.

The connection between the debugger plugin and the debugger-server-launcher plugin can be accomplished in the project settings.
But this is an area of the debugger interface that is not very good at the moment.