Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
Extend GDB plugin to communicate with other plugins
oBFusCATed:
There are two drivers at the moment - one for gdb and one for cdb.
This is the reason. This the original way the plugin has been coded, because there was no debugger apis in codeblocks at the time.
If it was done from scratch now - we'll have two separate plugins.
BlueHazzard:
So, here i am again...
I would really like to work on this, but there are some things to clear up first:
1) My final goal is to implement a svd file viewer as i described at the top. The svd file describes the internal peripheral register structure of a microprocessor (ARM, AVR, STM ecc...). This registers are located in the "RAM"-address space of the mcu (=microprocessor) and have nothing to do with the CPU core registers like the program counter or the cpu status register.
The later are read via the "reg" command in gdb. Peripheral register, on the other hand, are read by accessing the memory (x command). This means they have nothing in common. But i have seen some programs where this views are combined.
2) I don't see a urge necessity to recreate the cpu register dialog. There are all information listed and the dialog is quite simple. Of corse it could be made nicer and add some functions like reinterpreting of values and i am willing to work on this.
3) I would create a new plugin for this functionality. But then some interface to the debugger plugin is needed.
If the outcome of this discussion is to add this functionality to the cpu register window there are some things to clear:
1) Where store the path to the SVD file. There is the need of a project settings place. Probably the "Debugger" tab of the Project options
2) What control has to be used. I think the property grid is needed!
3) Is there the will of the devs to integrate my work in the code base (this point is always valid)
4) Because the cpu register and peripheral register are called from different gdb commands there is a lot of rework in the current gdb driver
5) This will add a "huge" xml parser for svd files, that has to be maintained, to the codeblocks code base
If the outcome is that i create a new plugin a interface to the gdb plugin is needed:
1) I can think of a universal interface
1.1) like "wxString SendCommandToCurrentActiveDebugger(wxString command)" what is blocking, takes a string as command and returns a string as response
1.2) Or a cb event? Something like request debugger command... with a global answer event, for all plugins...
2) It should be future proof, if there is at some point the transmission to the mi interface it should still work
3) like on top
i would really like some thoughts about this
Why to care:
Embedded development is a big part of the today c/c++ development. The only platform Independent IDEs i know for this is Eclipse and Codeblocks. And we don't talk about Eclipse here (big, slow, bloated). And for embedded development you need to debug, and for this a svd viewer is a essential part...
oBFusCATed:
--- Quote from: BlueHazzard on March 01, 2017, 09:20:36 pm ---If the outcome is that i create a new plugin a interface to the gdb plugin is needed:
1) I can think of a universal interface
1.1) like "wxString SendCommandToCurrentActiveDebugger(wxString command)" what is blocking, takes a string as command and returns a string as response
1.2) Or a cb event? Something like request debugger command... with a global answer event, for all plugins...
2) It should be future proof, if there is at some point the transmission to the mi interface it should still work
3) like on top
--- End quote ---
This will work only for current GDB's debugger, switching to GDB/mi will most probably break it, because the commands and the command's output is totally different. I suppose that LLDB also has different output no matter that it supports the mi protocol. So I suggest to discard this solution.
oBFusCATed:
--- Quote from: BlueHazzard on March 01, 2017, 09:20:36 pm ---If the outcome of this discussion is to add this functionality to the cpu register window there are some things to clear:
1) Where store the path to the SVD file. There is the need of a project settings place. Probably the "Debugger" tab of the Project options
2) What control has to be used. I think the property grid is needed!
3) Is there the will of the devs to integrate my work in the code base (this point is always valid)
4) Because the cpu register and peripheral register are called from different gdb commands there is a lot of rework in the current gdb driver
5) This will add a "huge" xml parser for svd files, that has to be maintained, to the codeblocks code base
--- End quote ---
1. This is fine, but this is only GDB's plugin UI. Other plugins will create separate tabs, so this is a bit grey area. I never got to make the per project UI unified. :(
2. The prop grid is a bit unstable and hard to use control, but this is the only option for wx2.8 and wx3.0. If we've switched to wx3. you could consider wxListTreeCtrl, but we have not so this is not an option
3. It depends on how it is done, the quality of the code, documentation, etc. For some of the variants I'll be reluctant to include them.
4. I don't think so, you'll have to add another cpu registers refreshing command, so I think it should be pretty straight forward
5. Why huge? It can be separated in a separate h/cpp files, so if it causes problems we could easily remove it. This should be in the gdb plugin for now
BlueHazzard:
Ok i have started some work, and i think for the beginning it does look neat:
https://github.com/bluehazzard/codeblocks_sf
i have added a search field to quick search through the names of the registers.
only wx2.8 at the moment
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version