Integrating custom Debuggers/Simulators to run from C::B

[scopaev]

First let me say C::B rocks! I have used too many interfaces in my career to count.
So many, I can barely remember how any of them work, in any detail.

I love the idea of a common IDE (as many seem to as well).

I have been able to successfully make multiple Microchip PIC compilers work with C::B (Compile & recognize errors/warnings properly).
Awesome fun!
--------------------
I would like to learn how to integrate off the shelf debuggers to work with C::B IDE as well.

To start, I am interested in trying to integrate MICROCHIP MBD to work in the background while I use the C::B debugger buttons (BREAKPOINTS, DEBUG, RUN, NEXT, WATCHES, ETC).
Microchip MDB seems to be a pretty straight forward command line controllable debugger. 

As an example:
  When I set a breakpoint in C::B, I want to write a command line that says:
    "break filename:linenumber" or "break *address"
  To setup a watch variable, I want to write a command line that says:
    "watch DataAddress"
 

Do I have to build a plugin, or can I simply use variables in a script file?

Can someone who has done this in the past, point me in the right direction (documentation, example code, anything)?

Any guidance is greatly appreciated.

[oBFusCATed]

If the debugger you're trying to integrate doesn't support gdb compatible commands, then the only options is to write a debugger plugin from scratch.

You can check the sources of the src/plugins/debuggergdb, which is the current debugger plugin for gdb/cdb.
I have started a gdb/mi style plugin that is a bit simpler, but it has not been updated for a while. See it here https://github.com/obfuscated/cb_gdbmi
I know that there is another implementation of the cdb debugger, but I don't have a link to it.
And there is a python plugin. You can find its sources here https://github.com/spillz/codeblocks-python

Take a look at these plugins and if you have questions don't hesitate to ask them.

There is a doxygen style documentations. You can read it in the code or generate it yourself.

[scopaev]

 

Thank you! I have never even heard of GDBMI.
I will read up on GDB and GDBMI to at least understand how they sort of work, and with any luck they may have some comand lines I could take advantage of.

What I was really hoping for (in the spirit of CB ease) was a sort of universal setup in the options_XXXX.xml file
This in turn would not require the end user (embedded programmers like me who know very little about GUI development) from having to create plugins in the future.

I would propose that a plugin would go into the options_xxx.xml file and pull up new debugger interface options AND link them to the existing CB Debugger buttons.

If anyone out there would like to collaborate on a CB plugin please contact me.
I can certainly do all the Command line investigation/interpretation/evaluation/specifications for both windows and linux (Debian).
Someone would have to be willing to take on the more complex role of GUI/Plugin developement (out of my league).


CONCEPTUAL XML file EXAMPLE:

Code

    <Program name="DBGconfig" value="GenericCli"/>
    
    <!-- Summary of Debug options -->
    <Category name="DBG_GENERIC_CLI_SETUP">
        <Option name="INSTALL_PATH_DBGR"               option="PlatformSpecificInstalDir/bin/"/>
        <Option name="FILENAME_DBGR"                   option="MDB.EXE"/>
        <Option name="CMD_RUN"                         option="Run"/>
        <Option name="CMD_CONTINUE"                    option="Continue"/>
      	<Option name="CMD_NEXT_LINE"                   option="Step"/>
      	<Option name="CMD_BREAK_DBGR"                  option="Halt"/>
      	<Option name="CMD_STOP_DBGR"                   option="Quit"/>
      	<Option name="CMD_BREAKPOINT_SET_LINE"         option="Break {$FileName}:{$LineNum}"/>
      	<Option name="CMD_BREAKPOINT_RESPONSE"         option="Breakpoint BREAKPOINT_ID at file FILENAME, line LINENUM."/>
      	<Option name="CMD_RMV_BREAKPOINT"              option="Delete {$BreakPointId}"/>
        <Option name="CMD_GET_VARIABLE"                option="Print {$CVariableToGet}"/>
        <Option name="CMD_SET_DEVICE"                  option="Device {$DeviceNumFromCompilerOptionsDeviceCategory}"/>
        <Option name="CMD_SET_DBG_FILE"                option="Program {$OutputFileName}"/>
        <Option name="CMD_EXTRA_0"                     option="Hwtool SIM"/>
        <Option name="CMD_EXTRA_1"                     option="Reset MCLR"/>
        <Option name="CMD_EXTRA_2"                     option=""/>
        <Option name="CMD_EXTRA_3"                     option=""/>
        <Option name="CMD_START_DBGR"                  option="INSTALL_PATH_DBGR/FILENAME_DBGR;CMD_SET_DEVICE;CMD_EXTRA_0;CMD_SET_DBG_FILE;CMD_EXTRA_1;"/>
    </Category>

CONCEPTUAL GUI PSEUDOCODE:   
    I realize this is oversimplified, but a pretty generic routine may look like this (I know this would work for the Microchip MDB):

Code

    WHEN CbBtnDebugContinue is Pressed: 
      If (Debugger is off) 
      {
        If (No Breakpoints set in C compiler): 
        {
          Display Error
        }
        Else
        {
          CMD_START_DBGR: That is run the following items in the command line, one at a time (So starting the gebugger is user settable!)
            EX:
              INSTALL_PATH_DBGR/FILENAME_DBGR   // Start the Chip Manufacturer Debugger
              CMD_SET_DEVICE                    // A "DEVICE" category Build Option needs to exist with only one device selected. Use that as the variable.
              CMD_EXTRA_0                       // Each Mfr Debugger is a little different. Having these "EXTRA" commands keeps this universal
              CMD_SET_DBG_FILE                  // Load the output debug file (Ex. ELF, COF, COD)
              CMD_EXTRA_1                       // Another extra starting command

          // Set Breakpoints
          Loop Through all breakpoints with: CMD_BREAKPOINT_SET_LINE (then parse through the CMD_BREAKPOINT_RESPONSE to get the Breakpoint Id & Save for later use)

          // Run the Debugger
          CMD_RUN

          // Debugger will hit first Breakpoint so update your watch variables (from debugger to IDE)
          Loop Through all Variables using: CMD_GET_VARIABLE
        }
      }
      
      If (Debugger is on ) 
      {
        CMD_CONTINUE
        Loop Through all Variables using: CMD_GET_VARIABLE // Update your watch variables (from debugger to IDE)
      }
      

      WHEN CbBtnRunToCursor is Pressed: 
        Set a breakpoint at the cursor line using CMD_SET_BREAKPOINT_LINE (and parse through the CMD_BREAKPOINT_RESPONSE to get the Breakpoint Id)
        CMD_CONTINUE
        Loop Through all Variables using: CMD_GET_VARIABLE // Update your watch variables (from debugger to IDE)
        Delete the breakpoint at the cursor line using CMD_RMV_BREAKPOINT (Using the Breakpoint Id)

      WHEN CbBtnNextLine is Pressed: 
        CMD_NEXT_LINE
        Loop Through all Variables using: CMD_GET_VARIABLE // Update your watch variables (from debugger to IDE)

      WHEN CbBtnBreakDebugger is Pressed: 
        CMD_BREAK_DBGR
       
      WHEN CbBtnStopDebugger is Pressed: 
        CMD_BREAK_DBGR
        CMD_STOP_DBGR

         
     

[oBFusCATed]

I doubt this is even possible. For sure it is not an easy task.
Most debuggers differ too much from each other. In the gdb plugin there is an base class Driver that tries to hide the differences between gdb and cdb, but it doesn't do a good job. Also keep in mind that patches which add another implementation of the driver won't be accepted, because I don't like the concept.

Also keep in mind that you don't have to do much gui programming in order to implement a debugger plugin.
Most of the ui is abstracted and it is common for all plugins. You just have to generate the data in the appropriate format and also handle some events.

[scopaev]

Thank you for your comments.  You input is greatly appreciated. 
If a dedicated plugin is what is allowed for a new debugger, then thats what I will have to learn to do.
Thanks for considering the concept.