Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

[New plugin] cbSystemView for embedded development

<< < (5/6) > >>

oBFusCATed:
Nope. Just cherry pick them and push them. I don't like the idea of automatic pulls, nor merge-push-generate-stupid-message thing github does. And some of the changes aren't meant to be pushed. If it has temp in the commit this commit is experimental.

I'd stick to a linear history, because it is possible that we'll want to put the sources in the main repo.

p.s. Should I push the changes to codeblocks?

BlueHazzard:
Ok, i looked now a bit more, and i have some suggestions:
1) Update the memory range only once, like the watches:

--- Code: ---diff --git a/src/plugins/debuggergdb/gdb_driver.cpp b/src/plugins/debuggergdb/gdb_driver.cpp
index e844ad69d..f4797e563 100644
--- a/src/plugins/debuggergdb/gdb_driver.cpp
+++ b/src/plugins/debuggergdb/gdb_driver.cpp
@@ -692,14 +692,18 @@ void GDB_driver::UpdateWatches(cb::shared_ptr<GDBWatch> localsWatch, cb::shared_
 
 void GDB_driver::UpdateMemoryRangeWatches(MemoryRangeWatchesContainer &watches)
 {
+    bool updateWatches = false;
     for (cb::shared_ptr<GDBMemoryRangeWatch> &watch : watches)
     {
         if (watch->IsAutoUpdateEnabled())
         {
             QueueCommand(new GdbCmd_MemoryRangeWatch(this, watch));
-            QueueCommand(new DbgCmd_UpdateWindow(this, cbDebuggerPlugin::DebugWindows::MemoryRange));
+            updateWatches = true;
         }
     }
+
+    if(updateWatches)
+        QueueCommand(new DbgCmd_UpdateWindow(this, cbDebuggerPlugin::DebugWindows::MemoryRange));
 }
 
 void GDB_driver::UpdateWatch(const cb::shared_ptr<GDBWatch> &watch)

--- End code ---

2) It would be cool to have a function, to add a bulk of watches, or to tell the DebuggerGDB::AddMemoryRange function to not perform an update right now (DebuggerGDB::AddMemoryRange(uint64_t address, uint64_t size,  const wxString &symbol, bool update = true)). The reason is, if i add a lot watches (like expanding the whole svd register tree at once) i get 1000 of update events (effectively for every memory range i add one). One possibility to solve this would be to pack all registers to one big memory watch, but i do not think that this is possible. The registers can have spaces between the memory ranges so that they can not be collected in one big memory range. This is not a show stopper for now, but it would be nice to have it in mind... This probably could also be helpful for the normal watches...

[edit:] About 2) if we extend AddMemoryRange with the not update parameter, probably a function to perform an update now would also be a nice to have (but not a necessity)

oBFusCATed:
Both things should be fixed in both codeblocks and plugin...
See the previously mentioned branches for the code.

Any testing would be helpful and welcome.
I plan to commit the changes to C::B's trunk in the next two weeks after I've the chance to use them in more of a production environment.

BlueHazzard:
Hi, i sadly hat not the time to fully test it...
I have some problems with my debugger...
But as far as i can tell it compiles :)

Do not know if i find time tomorrow...

oBFusCATed:
The changes to the Debugger API are in trunk. Now plugins had to be updated. Unfortunately the PythonDebugger would be broken :(

Navigation

[0] Message Index

[#] Next page

[*] Previous page