Extend GDB plugin to communicate with other plugins

[BlueHazzard]

For embedded arm development i would like to use the gdb debugger. But the current plugin is missing some features i would like o add (like a peripheral register watch ecc.). I would like to avoid to clone the current plugin but instead create a type of cross plugin communication... The easiest would be to add a function to send Commands to the debugger and return the answer from gdb... Probably over the event system for asynchronous calls?

Are there any thoughts, counter arguments?

[oBFusCATed]

I don't like the idea. If we do this then we need to have code that handles plugin deps and makes sure that dependant plugins are loaded before the plugin that needs them.
This is complex and error prone.

Why don't you just extend the cpu registers window with the needed functionality and the debugger api to match the needed features?
I'll be happy to guide you, review and commit the changes.

[BlueHazzard]

I don't like the idea. If we do this then we need to have code that handles plugin deps and makes sure that dependant plugins are loaded before the plugin that needs them.
This is complex and error prone.

I see the problem here... Couldn't this be handled by using events? If the receiver plugin is not loaded the the events simply get to nirvana and the plugin detects it somehow over a timeout (wild speculations here)...

Why don't you just extend the cpu registers window with the needed functionality and the debugger api to match the needed features?
I'll be happy to guide you, review and commit the changes.

I am not happy with extending the current plugin with the features, because i would like to make something like this:

and for this i need a .svd file parser and so on. This would bloat the plugin and if someone is not using the embedded stuff this is not needed...

An other possibility would be to extend the watch parsing (squirrel) with the ability to modify the controls....

[oBFusCATed]

and for this i need a .svd file parser and so on.

What is a svd file?

I am not happy with extending the current plugin with the features, because i would like to make something like this:

Do you need this to be a tree ctrl?

This would bloat the plugin and if someone is not using the embedded stuff this is not needed...

It could be enabled per configuration and not on by default.

An other possibility would be to extend the watch parsing (squirrel) with the ability to modify the controls....

Don't do this, the squirrel code in the debugger plugin will be removed as soon as I finish merging the sqrat stuff.

[BlueHazzard]

What is a svd file?

for ex. http://www.keil.com/pack/doc/cmsis/svd/html/svd__example_pg.html The file describes the internal periphery register structure of arm and other µC (i know the files also for  atmega/xmega)..

Do you need this to be a tree ctrl?

i don't know the UI yet.... some kind of property grid, it should have the possibility to use drop down menus,check boxes and text fields. Custom controls like leds (red dots) would also be nice...  A search field would also be needed, because there can be ton's of register and flag names

Quote from: BlueHazzard on Yesterday at 18:54:32
This would bloat the plugin and if someone is not using the embedded stuff this is not needed...

It could be enabled per configuration and not on by default.

By bloating i mean code/ binary size... More things to maintain for the main dev team Of corse it is possible to add it at the core and make it configurable, but i don't like the idea to add something to the main plugin what is not needed for the core. Because there is also potential for more logging/debugging like:

I don't think this functionality should be in the core. But if you want to use codeblocks  (i think there is no really nice, cross platform and fast IDE for debugging embedded systems out there) for embedded development you "need" this things. It would simply be nice to have somehow an interface to gdb...

Quote from: BlueHazzard on Yesterday at 18:54:32
    An other possibility would be to extend the watch parsing (squirrel) with the ability to modify the controls....

Don't do this, the squirrel code in the debugger plugin will be removed as soon as I finish merging the sqrat stuff.

Sad... i think there would be a lot potential. Specially in automation of gdb things and embedded stuff (see previous image)...

[oBFusCATed]

for ex. http://www.keil.com/pack/doc/cmsis/svd/html/svd__example_pg.html The file describes the internal periphery register structure of arm and other µC (i know the files also for  atmega/xmega)..

I think some of the embedded forks of cb has a parser for this added to the wizard.

i don't know the UI yet.... some kind of property grid, it should have the possibility to use drop down menus,check boxes and text fields. Custom controls like leds (red dots) would also be nice...  A search field would also be needed, because there can be ton's of register and flag names

Unfortunately the propgrid is the best ui for this, but I'm not sure I like this control. Especially the migration from 2.8 to 3.x.

By bloating i mean code/ binary size... More things to maintain for the main dev team Of corse it is possible to add it at the core and make it configurable, but i don't like the idea to add something to the main plugin what is not needed for the core.

Don't worry too much about this. The cpu registers window needs improvements. If you make them general enough it might be good for all users.
And there people which will be happy to use something like cb, instead of the vendors ides.

Because there is also potential for more logging/debugging like:

I don't think this functionality should be in the core. But if you want to use codeblocks  (i think there is no really nice, cross platform and fast IDE for debugging embedded systems out there) for embedded development you "need" this things. It would simply be nice to have somehow an interface to gdb...

This is totally separate topic and probably a lot more work and it is better to discuss it later, when the cpu registers problem is solved.

The problems with interfacing with the debugger from another plugin is that:
1. parsing the output is hard and is done on per command basis, so you need to do some parsing in your plugin.
2. you make a connection where your plugin starts to depend on the behaviour of one particular debugger plugin, which is not a good idea.

Sad... i think there would be a lot potential. Specially in automation of gdb things and embedded stuff (see previous image)...

Now we have python printers directly in gdb, which do better job handling the watches. Our scripts for the watches need lots of work, I'm not sure how to do even. We need a way to execute a command, wait for its output, parse it, execute another command and so on.
If you have idea where scripting might help, I'm ready to discuss them.

[oBFusCATed]

And for the record I don't like the idea to have two separate cpu registers windows - one for host and one for embedded development.

[BlueHazzard]

I think some of the embedded forks of cb has a parser for this added to the wizard.

I have looked into emBitz, but it is somehow closed source and won't run on linux...

Don't worry too much about this. The cpu registers window needs improvements. If you make them general enough it might be good for all users.
And there people which will be happy to use something like cb, instead of the vendors ides.

And for the record I don't like the idea to have two separate cpu registers windows - one for host and one for embedded development.

The thing is this: periphery register are not cpu registers... (like the program counter or the cpu status register) this register are read with the info registers command of gdb.
Periphery register on the other hand are located on a special memory location and read with the x command.

It is possible to merge this two register views, but i don't know if this is a wide spread opinion...

[oBFusCATed]

I have looked into emBitz, but it is somehow closed source and won't run on linux...

Does it still look like code::blocks 10.05?

It is possible to merge this two register views, but i don't know if this is a wide spread opinion...

Why not?

[BlueHazzard]

I looks somehow like visual studio 2012 or so... And the settings ui is quite different, i had difficulties to find me around...

Why not?

Well lets try it...

Can you give me some overlook over the architecture?
What is the intention to not call (queue) the debugger commands from the DebuggerGDB class, but translate them  through the driver?

[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]

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

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]

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

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