Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
Extend GDB plugin to communicate with other plugins
BlueHazzard:
i continued my work and have now finished the svd file parser.
My next step is to implement the api to read the periphery register from the microcontroller.
I thought a lot about this and i think the best solution would be to implement "memory watches". They would be implemented like the current watches but instead to use the "print" gdb command they would use "x" command.
Any thoughts about this?
On a second thought, i would like to save the window, where the watch is, into the "cbWatch" class (and also into the new cbMemoryWatch class). This would enable the ability to use the same memory watch for the ExamineMemory dialogue and the periphery register dialogue. This would also allow to add multiple memory windows and watch windows like they exist in other IDEs.
oBFusCATed:
Multiple watch windows aren't implemented because wxAUI doesn't support moving one pane to a random notebook, so there is no UI space left. Unfortunately I don't think wx will add this feature any time soon, so we'll have to probably think about some hacky solution. :(
For the memory watches - just add the appropriate flags in the GDBWatch class and do separate processing based on these flags.
I don't understand all the talk about the ExamineMemory dialogs...
Keep in mind that working on the current gdb plugin will most probably be a waste of your time...
Do you have some branch somewhere I can look at?
BlueHazzard:
--- Quote ---Multiple watch windows aren't implemented because wxAUI doesn't support moving one pane to a random notebook, so there is no UI space left. Unfortunately I don't think wx will add this feature any time soon, so we'll have to probably think about some hacky solution. :(
--- End quote ---
Multiple tabs for the watches window? Anyway, this is not part of this discussion, i wanted only show a second use case.
For future discussion: Keep in mind that i want to implement this on codeblocks sdk level, not GDB-plugin level, because the functionality is debugger agnostic. If the debugger supports memory read out (as the most do) the debugger supports svd/register readout
--- Quote ---For the memory watches - just add the appropriate flags in the GDBWatch class and do separate processing based on these flags.
--- End quote ---
So you think about modifying the cbWatch class? This would be ok, what about to store the owner of the watch?
--- Quote ---I don't understand all the talk about the ExamineMemory dialogs...
--- End quote ---
on embedded development it is quite handy
--- Quote ---Keep in mind that working on the current gdb plugin will most probably be a waste of your time...
--- End quote ---
I don't think so:
1) We are talking about to replace the gdb plugin for years now, at the plugin is still the old
2) I need this functionality quite often...
3) As i mentioned at the top this is debugger agnostic
--- Quote ---Do you have some branch somewhere I can look at?
--- End quote ---
i have started some work here: https://github.com/bluehazzard/codeblocks_sf on the new_cpu_register_window_01 branch
[Edit:] The svd parser is not pushed yet...
oBFusCATed:
Let me know when you have everything published, so I can inspect it fully.
One note don't add non generic stuff to sdk classes. I can see you're adding some svd fields in the project. This is not a good idea. Add some generic storage and provide a way to define multiple parsers. As far as I can see svd is arm only and thus it is not generic.
For cbWatch, I don't know if I like the idea to be used in the cpu register ui. For sure I don't want to store pointers to windows in it. Probably you can add something like a purpose field or something like this. And definitely it is not good idea to use it in the examine memory window. This window must be made to work with arrays of bytes...
There a few subsystems of cb that are in worse state than the debugger, so they have priority in my todo at the moment.
BlueHazzard:
--- Quote ---One note don't add non generic stuff to sdk classes. I can see you're adding some svd fields in the project. This is not a good idea. Add some generic storage and provide a way to define multiple parsers. As far as I can see svd is arm only and thus it is not generic.
--- End quote ---
You know, exactly this is the point i wanted to state on the top of this discussion. This should not be part of the sdk or the debugger plugin, but you said me that it is ok to implement this kind of stuff into the sdk. I don't like this idea, so i will go one step back and try some other approach:
1) Extend the SDK with a class called cbMemoryWatch (pseudocode):
--- Code: ---class cbMemoryWatch
{
uint64_t m_address; // start address of the memory watch
uint64_t m_count; // count of bytes
vector<uint8_t> m_data; // The actual data
bool IsChanged() const;
const std::vector<uint8_t>& GetData()
}
--- End code ---
This class will hold a watch on a continuous memory (RAM) area with m_count size. (so for example 256 Bytes form address 0x331E34 )
Extend the cbDebuggerPlugin class with this API functions:
--- Code: ---virtual cb::shared_ptr<cbMemoryWatch> AddMemoryWatch(const uint64_t address, const uint64_t count) = 0;
virtual void DeleteMemoryWatch(cb::shared_ptr<cbMemoryWatch> watch) = 0;
virtual bool HasMemoryWatch(cb::shared_ptr<cbMemoryWatch> watch) = 0;
virtual bool SetMemoryWatchValue(cb::shared_ptr<cbMemoryWatch> watch, const std::vector<uint8_t>& value) = 0;
virtual void UpdateMemoryWatch(cb::shared_ptr<cbMemoryWatch> watch) = 0;
--- End code ---
the MemoryWatches will get updated like the normal watches on every hold of the debugger, but with the "x" gdb command and not with "print" like the watches.
With this API it should be possible to implement a SVD (or any other) view as a plugin.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version