Author Topic: [New plugin] cbSystemView for embedded development  (Read 22391 times)

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: [New plugin] cbSystemView for embedded development
« Reply #15 on: January 07, 2019, 10:37:46 pm »
More general comments on the code of the plugin:
1. Try to use unique_ptr and shared_ptr more often. You have tons of places where you use delete and this is error prone.
2. This
Code
cbDebuggerPlugin *dbg = Manager::Get()->GetDebuggerManager()->GetActiveDebugger();

could return nullptr. Never use the dbg pointer without checking it! It is possible to have no active debugger if there are no debugger plugins loaded!
3. FindString seems a redundant and slow reimplementation of some of the methods in wxString. If there is particular reason it is good if you can write a comment about it.
4. There is no good reason to use std::list in 2019. It is slower than std::vector. If you don't believe me, search the internet for details. If for some reason you need to use a linked list you'll do it manually, because you'll have more complex data structure and you won't be storing the elements in a container.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: [New plugin] cbSystemView for embedded development
« Reply #16 on: January 07, 2019, 11:48:14 pm »
Another note I've just remembered. Using the active debugger is not a good idea. In theory it could change in the middle of a debugging session. What you should do is something similar to the watches dlg which uses this code:
Code
cbDebuggerPlugin *plugin = Manager::Get()->GetDebuggerManager()->GetDebuggerHavingWatch(watch);
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: [New plugin] cbSystemView for embedded development
« Reply #17 on: February 10, 2019, 12:16:02 am »
The modified patches by bluehazzard has been pushed to this branch: https://github.com/obfuscated/codeblocks_sf/commits/debugger/memory_watches

And here is a branch to a modified version of the plugin to make use of the new features: https://github.com/obfuscated/cbSystemView/tree/debugger/memory_watches

@bluehazzard: Please test and let me know if I broke something vital. At the moment the only thing that is a bit different is that no notifications are sent for every memory range. Just one at the end. Probably this is not the best way to do it, but it is not something that it is hard to do. Just I'm a bit cautious because sending too many events too quickly it is not really fast.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 3353
Re: [New plugin] cbSystemView for embedded development
« Reply #18 on: February 10, 2019, 02:37:33 pm »
i will test it the next week! Thank you for your work!

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 3353
Re: [New plugin] cbSystemView for embedded development
« Reply #19 on: February 14, 2019, 10:03:45 pm »
FIrst quick look it seems to work nicely and fast! Thank you! I think we are on a great path here!

There are some quirks, for example the update indicator is not in sync after the first halt and expanding all entries with the toolbar button will make the update dialog flash many times, instead of indicating all the update time.

I will look into this.
Can you make a pull request on github, so i can pull your changes?

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: [New plugin] cbSystemView for embedded development
« Reply #20 on: February 15, 2019, 08:23:41 am »
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?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 3353
Re: [New plugin] cbSystemView for embedded development
« Reply #21 on: February 16, 2019, 11:06:45 am »
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)

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)
« Last Edit: February 16, 2019, 11:13:50 am by BlueHazzard »

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: [New plugin] cbSystemView for embedded development
« Reply #22 on: April 14, 2019, 03:49:12 pm »
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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 3353
Re: [New plugin] cbSystemView for embedded development
« Reply #23 on: April 16, 2019, 09:03:41 pm »
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...

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: [New plugin] cbSystemView for embedded development
« Reply #24 on: April 21, 2019, 10:15:53 am »
The changes to the Debugger API are in trunk. Now plugins had to be updated. Unfortunately the PythonDebugger would be broken :(
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 3353
Re: [New plugin] cbSystemView for embedded development
« Reply #25 on: April 22, 2019, 11:06:13 pm »
Ok, i tested it now and it seems to work on windows 7.

The plugin still needs some tweaks, but the api is fine and should work!

great!

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 3353
Re: [New plugin] cbSystemView for embedded development
« Reply #26 on: April 22, 2019, 11:25:41 pm »
The problem with the debugger i had, by not be able to send a ctrl+c to the gdb trough codeblocks was because i run codeblocks with codeblocks... If i run codeblocks directly i am able to send the ctrl+c....

Not working:
Code
codeblocks->codeblocks->arm_gdb->arm_gdb_server
working:
Code
codeblocks->arm_gdb->arm_gdb_server
this has probably something to do with the executable group... I think at some time we need to introduce a proxy program for gdb.... (also the 32bit <-> 64 bit thing would be solved by this) but this is for later...

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: [New plugin] cbSystemView for embedded development
« Reply #27 on: April 23, 2019, 08:29:12 am »
What do you mean by proxy program? On windows any gdb which supports python is setup to start two executables gdb and gdb_orig... This causes lots of problems...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: [New plugin] cbSystemView for embedded development
« Reply #28 on: April 23, 2019, 04:49:23 pm »
On windows any gdb which supports python is setup to start two executables gdb and gdb_orig...
I think only GDB supplied from mingw-w64(original name is mingw-build) has such two gdb executables. I don't know why they need such changes, maybe they want to load the python pretty printer automatically by the proxy-gdb.

For me, I use GDB build myself, I don't use such proxy-gdb. ;)
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: [New plugin] cbSystemView for embedded development
« Reply #29 on: April 23, 2019, 07:07:00 pm »
The gdb from tdm I had also had these two executables and yes they probably use it to setup correct python environment. But this is not what CB expects and there are problems.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]