Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
[New plugin] cbSystemView for embedded development
oBFusCATed:
--- Quote from: BlueHazzard on January 06, 2019, 06:22:51 pm ---Yes it is depended... I have not optimized the plugin. I wanted first to be sure that the plugin will work with trunk codeblocks before i optimize it, add add other features (see below)
--- End quote ---
But doing it like that we'll have a chicken/egg problem, because I'm looking at the pluign to find the best way to design the API. 8) As you probably know I don't like the pause/continue patch. So I want to find a better solution.
Do you want to be able to cancel the update of multiple mem-watches? Do you think this works now?
p.s. I'm on linux and I'm using relatively new wx-master and asan.
BlueHazzard:
--- Quote from: oBFusCATed on January 06, 2019, 06:53:53 pm ---
--- Quote from: BlueHazzard on January 06, 2019, 06:22:51 pm ---Yes it is depended... I have not optimized the plugin. I wanted first to be sure that the plugin will work with trunk codeblocks before i optimize it, add add other features (see below)
--- End quote ---
But doing it like that we'll have a chicken/egg problem, because I'm looking at the pluign to find the best way to design the API. 8) As you probably know I don't like the pause/continue patch. So I want to find a better solution.
--- End quote ---
I think codeblocks should provide an api for getting ranges of memory, somehow performant (or at least as far as gdb allows it) But it should not be depended on the application, so optimizing for embedded systems is from my perspective not the best idea... Can you draw an image of your idea of the api? What do you mean by separate workflow?
--- Quote ---Do you want to be able to cancel the update of multiple mem-watches? Do you think this works now?
--- End quote ---
If it is possible it would be nice... But does GDB let you do it? What do you mean by "now" ?
If you work on this, you can also think about an api to send general commands to the debugger, something like a queue ;)
oBFusCATed:
--- Quote from: BlueHazzard on January 06, 2019, 07:15:55 pm ---Can you draw an image of your idea of the api? What do you mean by separate workflow?
--- End quote ---
The current behaviour uses the pause event to know when a command has finished. As expressed in multiple places. This is a bad idea, because it ties your plugin to the current implementation of the debugger plugin.
What I want to do is to provide a call like:
UpdateMemWatches which is called from your plugin.
This call would send an event when one/all mem watches are updated.
Not sure if separate events are useful, but probably you can tell me. 8)
Probably there could be another api which could be used to cancel the update of a given watch.
--- Quote from: BlueHazzard on January 06, 2019, 07:15:55 pm ---If it is possible it would be nice... But does GDB let you do it? What do you mean by "now" ?
--- End quote ---
"Now" means your current implementation in your repo.
By cancel I mean cancel execution of the next command. I doubt it is possible to cancel commands. In the terminal you can press ctrl-c, but I doubt this would be reliable. It could be tested, but I prefer to spend time doing work on gdb/mi than this.
--- Quote from: BlueHazzard on January 06, 2019, 07:15:55 pm ---If you work on this, you can also think about an api to send general commands to the debugger, something like a queue ;)
--- End quote ---
I don't want to think about such API. This would never work reliably. I've stated this multiple times. If something needs to send commands to the debugger it would be a lot easier to make it a part of the debugger plugin than to make it an external plugin which talks to the debugger.
BlueHazzard:
--- Quote ---The current behaviour uses the pause event to know when a command has finished. As expressed in multiple places. This is a bad idea, because it ties your plugin to the current implementation of the debugger plugin.
--- End quote ---
Ok, i understand this, and i am completely on your side about this. Currently it is a bad implementation, but i used what was present (and not implemented xD, only the defines where there )
--- Quote ---What I want to do is to provide a call like:
UpdateMemWatches which is called from your plugin.
This call would send an event when one/all mem watches are updated.
Not sure if separate events are useful, but probably you can tell me. 8)
--- End quote ---
If i understand you correctly (i think it today is to late for me to discuss this properly) the debugger plugin sends an event when all (one) MemWatch is updated from the debugger? This is a nice implementation. One event pro watch would be cool, so we can update all windows continuously (for example if the memory window uses also MemoryWatches). How do you pass what watch has been updated to the event? Some kind of id? The pointer address? From this point one event for all watches would be more easy. I have no strong opinion about this....
--- Quote ---"Now" means your current implementation in your repo.
By cancel I mean cancel execution of the next command. I doubt it is possible to cancel commands. In the terminal you can press ctrl-c, but I doubt this would be reliable. It could be tested, but I prefer to spend time doing work on gdb/mi than this.
--- End quote ---
I have no strong opinion about the cancel.. If it is needed the plugin can remove the watch with the implemented api call and then ignore the event. What the debugger plugin does with this is a other point. As far as i can see we can not stop gdb so we should not waste time on this...
--- Quote ---I don't want to think about such API. This would never work reliably. I've stated this multiple times. If something needs to send commands to the debugger it would be a lot easier to make it a part of the debugger plugin than to make it an external plugin which talks to the debugger.
--- End quote ---
ok. i do not want to recook this whole topic. Some last question:
How do you think it is possible to send "remote reset" to the debugger from within codeblocks? Some toolbar button would be nice. There are other "remote" commands, like uploading new code ecc... This is essential for debugging embedded systems properly...
oBFusCATed:
--- Quote from: BlueHazzard on January 06, 2019, 09:05:05 pm ---If i understand you correctly (i think it today is to late for me to discuss this properly) the debugger plugin sends an event when all (one) MemWatch is updated from the debugger? This is a nice implementation. One event pro watch would be cool, so we can update all windows continuously (for example if the memory window uses also MemoryWatches). How do you pass what watch has been updated to the event? Some kind of id? The pointer address? From this point one event for all watches would be more easy. I have no strong opinion about this....
--- End quote ---
This sound too generic. For now I think I'll concentrate on memory watches only. If it works well we could port this to other parts.
--- Quote from: BlueHazzard on January 06, 2019, 09:05:05 pm ---Some last question:
How do you think it is possible to send "remote reset" to the debugger from within codeblocks? Some toolbar button would be nice. There are other "remote" commands, like uploading new code ecc... This is essential for debugging embedded systems properly...
--- End quote ---
What does "remote reset" mean in the first place? How do you do it? Is it different for different mcus? How often do you need to do it?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version