Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
Extend GDB plugin to communicate with other plugins
oBFusCATed:
--- Quote from: BlueHazzard on July 31, 2017, 09:50:38 pm ---With this kind of watch it would be possible to do all this things from a plugin.
--- End quote ---
I really doubt it. Especially if you want to transfer tons of data.
--- Quote from: BlueHazzard on July 31, 2017, 09:50:38 pm ---At the moment i would like to implement it and for this i need to know what api the devs would support.
--- End quote ---
It will be good if you could try the minimal version of the watch idea. In order to see if it is worth pursuing. Nothing fancy and complex on the UI part. Get adding (use some hardcoded path to a svd file for example) and updating watches to work. My original thought was to put the register watches in the watches window, because it will make it easier to experiment with it.
--- Quote from: BlueHazzard on July 31, 2017, 09:50:38 pm ---For optimization is later time, if the bottleneck is found.
--- End quote ---
The problem with api design is that you should design for performance up front. It is very hard to make a system really performant if the api is not optimal.
--- Quote from: BlueHazzard on July 31, 2017, 09:50:38 pm ---Why is this a bad idea?
--- End quote ---
It creates delays for the user when you need the data. I guess here it won't be that bad and it could be disabled if it creates too many ux problems. I'm not sure I like the similar implementation in the gdb/mi plugin.
--- Quote from: BlueHazzard on July 31, 2017, 09:50:38 pm ---...because from my experience the problem is codeblocks<->gdb and not gdb or codeblocks at program level.
--- End quote ---
Sometimes gdb is slow, because it has tons of data to process and produces small amount of data.
--- Quote from: BlueHazzard on July 31, 2017, 09:50:38 pm ---In any way it is faster then updating the whole register map (if the map is 11kByte big, on smaller targets it may be a possibility...)
--- End quote ---
This could be done in the gdb plugin. Because it is its job to iterate the register-watches and decide what commands to issue. It might be possible to merge different memory ranges. If they overlap or next to each other.
BlueHazzard:
I tried to implement the way you suggested. We need to distinguish between a "symbol" watch and a "memory" watch, because the gdb command for asking a symbol is "output" and for a memory region it is "x". Now my first try is to make the distinguish within the watch. For this is have to:
1) Extend the cbWatch class with
--- Code: ---
enum cbWatchType
{
cbWatchType_SYMBOL,
cbWatchType_MEMORY
};
virtual void AddMemoryRange(uint64_t address, uint64_t size, const wxString &id ) = 0;
cbWatchType GetWatchType() {return m_watchType;};
private:
cbWatchType m_watchType;
--- End code ---
2) Modify the GDBWatch class:
--- Code: ---void GDBWatch::AddMemoryRange(uint64_t address, uint64_t size, const wxString &id )
{
m_symbol = wxString::Format(wxT("/%ulub %lx"), size, address);
m_watchType = cbWatchType_MEMORY;
}
void GDBWatch::SetSymbol(const wxString& symbol)
{
m_symbol = symbol;
m_watchType = cbWatchType_SYMBOL;
}
--- End code ---
now my plan was to modify the class GdbCmd_Watch to distinguish between memory and symbol watch
--- Code: --- GdbCmd_Watch(DebuggerDriver* driver, cb::shared_ptr<GDBWatch> watch) :
DebuggerCmd(driver),
m_watch(watch)
{
wxString type;
wxString symbol;
m_watch->GetSymbol(symbol);
m_watch->GetType(type);
if(m_watch->GetWatchType == cbWatchType_MEMORY)
{
m_Cmd << "x " << symbol;
return;
}
// old code from here on
type.Trim(true);
type.Trim(false);
m_Cmd = static_cast<GDB_driver*>(m_pDriver)->GetScriptedTypeCommand(type, m_ParseFunc);
if (m_Cmd.IsEmpty())
{
--- End code ---
Now i wanted to modify the
--- Code: ---ParseGDBWatchValue
--- End code ---
function to parse a memory and symbol watch differently. But it is not that easy....
There is also the GdbCmd_FindWatchType command. I have discovered that the process for updating a watch is to
1) Queue a GdbCmd_FindWatchType command.
2) After successful action this command queues a GdbCmd_Watch
Now the GdbCmd_FindWatchType is useless for the memory watch. So i have to insert even more logic, or modify it future up...
Is this really the way you want to go?
oBFusCATed:
Why do you want to reuse the watch parsing and querying in the gdb plugin?
When adding memory watches you can add them to a separate array of objects and treat them differently inside the plugin.
The idea is to reuse the interface of cbWatch, but not the implementation inside the plugin.
I don't see why the cbWatch needs to have a type at this point in time of development.
Probably when you start to do the UI you'll have to add some field that is used to specify the widget and some what to get the data for the widget, but you are not at this step yet.
p.p. C::B is using C++11 now, so you can take advantage of the better enums and don't have to explicitly add namespace.
BlueHazzard:
ok, i have now implemented a first version of the whole thing:
https://youtu.be/ELOoFKLemmQ
i will upload the source code to github as soon as possible...
BlueHazzard:
Ok, codeblocks code is here:
https://github.com/bluehazzard/codeblocks_sf/tree/debugger/memory_range_watch
for the plugin code i need more time. I have to clean up a bit...
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version