User forums > Embedded development
Is there a way to create a "Debug Target" using scripting?
Aerodesic:
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
oBFusCATed:
--- Quote from: Aerodeisc on August 09, 2015, 11:20:45 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.
--- End quote ---
This won't work. cbDebuggerPlugin is an abstract class and instances are only available in the debugger plugins.
--- Quote from: Aerodeisc on August 09, 2015, 11:20:45 pm ---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.
--- End quote ---
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: ---dbgObj=getDebugger("gdb");
dbgObj.setA(...);
dbgObj.setB(...);
etc.
--- End code ---
--- Quote from: Aerodeisc on August 09, 2015, 11:20:45 pm ---Speaking of 'roadmap', is there an update somewhere as to plans? The latest one I find seems to stop at version 1.5.
--- End quote ---
Nope, no one bothers to maintain it, because no one follows it.
BlueHazzard:
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
oBFusCATed:
As far as I could understand he wants to write a script that can setup the remote debugging options for the gdb debugger.
Aerodesic:
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...
Navigation
[0] Message Index
[#] Next page
Go to full version