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

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 2566
[New plugin] cbSystemView for embedded development
« on: October 16, 2017, 04:32:59 am »
Hi,
i made a new plugin for codeblocks: cbSystemView https://github.com/bluehazzard/cbSystemView
This plugin allows to read SVD Files and display registers accordingly during debugging sessions.

NOTE: This plugin does not work with current codeblocks. It needs some modification, i have done them on this branch: https://github.com/bluehazzard/codeblocks_sf/tree/debugger/pull_candidate/memory_range_watch/1

i hope they find their way into the main branch. The modifications are discussed here: http://forums.codeblocks.org/index.php/topic,21457.30.html

Who needs this plugin?
If you work with embedded systems (mostly ARM controller) this plugin helps you a lot during the development. Eclipse has it too: https://sourceforge.net/projects/embsysregview/
it still needs some work, but it is a good start and all basic functionality is there.

greetings

Offline Quiss

  • Multiple posting newcomer
  • *
  • Posts: 74
Re: [New plugin] cbSystemView for embedded development
« Reply #1 on: October 25, 2017, 12:49:46 pm »
Hi,

I've built your modified cb and plugin without error. But this shows up after clicking a menu item (like Help->About):


As I've searched a little bit, I think it has something to do with Windows 10 (and 8 ) and this wx version: https://github.com/pcsx2/pcsx2/issues/853#issuecomment-143596989

Windows 10 - 1703, Tdm-gcc-5.1.0, wxWidgets 3.0.2

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 2566
Re: [New plugin] cbSystemView for embedded development
« Reply #2 on: October 25, 2017, 01:07:28 pm »
I do not use win10 so i can not tell anything about this.
Is this problem also with the normal build of codeblocks?
i build it with wx3.1 so maybe this helps...

Offline Quiss

  • Multiple posting newcomer
  • *
  • Posts: 74
Re: [New plugin] cbSystemView for embedded development
« Reply #3 on: October 25, 2017, 03:18:30 pm »
I've just built https://github.com/obfuscated/codeblocks_sf (SHA-1: e7d2a6627cd08fb290048026b859dd8a57f7875e), the same problem exists. Let me try with wx3.0.3 before 3.1.

Edit: 3.0.3 is ok. Occurences highlighting does not work but it doesn't work in main cb either.
« Last Edit: October 27, 2017, 07:10:25 am by Quiss »

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12123
    • Travis build status
Re: [New plugin] cbSystemView for embedded development
« Reply #4 on: December 23, 2018, 11:22:28 am »
@bluehazzard:

I'm looking at the memory watches patch and have a question:
Do you add all elements in the tree as memory range watches? Or do you just add the root ones?
To me it seems that you don't just add the root ones as is done in the normal watches.
Does it make sense to do the same thing? Is it to limiting?

I'm asking, because doing it like it is done would affect performance more compared to the way the normal watches are done.
Generally for normal watches it is expected that you have very small number of watches, but with svd files you could have hundreds of registers and their views.
(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: 2566
Re: [New plugin] cbSystemView for embedded development
« Reply #5 on: December 23, 2018, 04:25:07 pm »
Quote
To me it seems that you don't just add the root ones as is done in the normal watches.
Does it make sense to do the same thing? Is it to limiting?
I do not see how this influences the "MemoryWatches". At the moment i make a watch for every element that is expanded and not only the root. I do this, because the address range of the registers can contain address jumps from one register to the other (and they can be MBytes large). It is not guaranteed that between this "jumps" are valid addresses that can be read. Of course this is not performant. A good plugin should check the range of the watches, and if it is one big continuous range it should collect this and make one big watch. But i do not think this logic should be part of codeblocks,but rather part of the plugin. The watches should be as universal as possible (For example to use them as memory viewer of the normal codeblocks https://github.com/bluehazzard/cbMemoryView )...

Quote
but with svd files you could have hundreds of registers and their views.
Yes this is a problem, and it makes the plugin painful slow, but i have written this limitation in the README. It is not really a limitation, because it would get confusing pretty fast if you expand a lot registers, so it is not the normal use case. If it is really a user problem the plugin can be extended with the logic mentioned above pretty easy. Because of the slow update rate for many watches i need events to inform the user that all watches are updated.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12123
    • Travis build status
Re: [New plugin] cbSystemView for embedded development
« Reply #6 on: January 06, 2019, 04:48:37 pm »
I'm getting crashes if I expand a register which the debugger cannot access.

Code: [Select]
#0  0x00007ffff442dd94 in wxPGChoicesData::Item (this=0x0, i=0) at ../git/include/wx/propgrid/property.h:673
#1  0x00007ffff442deae in wxPGChoices::Item ([email protected]=0x61600172bdb8, [email protected]=0) at ../git/include/wx/propgrid/property.h:887
#2  0x00007ffff442aaef in wxPGChoices::operator[] (i=0, this=0x61600172bdb8) at ../git/include/wx/propgrid/property.h:950
#3  wxPGProperty::GetDisplayInfo ([email protected]=0x61600172bc80, [email protected]=1, [email protected]=0, [email protected]=0, [email protected]=0x7fffffffc580, [email protected]=0x7fffffffc500) at ../git/src/propgrid/property.cpp:839
#4  0x00007ffff442b274 in wxPGDefaultRenderer::Render (this=0x602000057230, dc=..., rect=..., propertyGrid=0x61c000042880, property=0x61600172bc80, column=1, item=-1, flags=0) at ../git/src/propgrid/property.cpp:256
#5  0x00007ffff4444cf6 in wxPropertyGrid::DoDrawItemsBase ([email protected]=0x61c000042880, dc=..., [email protected]=0x7fffffffcac0, [email protected]=true) at ../git/src/propgrid/propgrid.cpp:2488
#6  0x00007ffff44453d3 in wxPropertyGrid::DoDrawItems (itemsRect=0x7fffffffcac0, dc=..., this=0x61c000042880) at ../git/include/wx/propgrid/propgrid.h:1824
#7  wxPropertyGrid::DrawItems ([email protected]=0x61c000042880, dc=..., topItemY=<optimized out>, bottomItemY=<optimized out>, [email protected]=0x7fffffffcac0) at ../git/src/propgrid/propgrid.cpp:1999
#8  0x00007ffff44459a0 in wxPropertyGrid::OnPaint (this=0x61c000042880) at ../git/src/propgrid/propgrid.cpp:1879
#9  0x00007ffff28199f6 in wxAppConsoleBase::HandleEvent (this=<optimized out>, handler=<optimized out>, func=<optimized out>, event=...) at ../git/src/common/appbase.cpp:657
#10 0x00007ffff2819a3a in wxAppConsoleBase::CallEventHandler (this=0x61a00001e680, handler=0x61c000042880, functor=..., event=...) at ../git/src/common/appbase.cpp:669
#11 0x00007ffff29b5e63 in wxEvtHandler::ProcessEventIfMatchesId (entry=..., [email protected]=0x61c000042880, event=...) at ../git/src/common/event.cpp:1396
#12 0x00007ffff29b814f in wxEventHashTable::HandleEvent (this=<optimized out>, event=..., [email protected]=0x61c000042880) at ../git/src/common/event.cpp:1004
#13 0x00007ffff29b81fa in wxEvtHandler::TryHereOnly ([email protected]=0x61c000042880, event=...) at ../git/src/common/event.cpp:1593
#14 0x00007ffff29b8266 in wxEvtHandler::TryBeforeAndHere (event=..., this=0x61c000042880) at ../git/include/wx/event.h:3892
#15 wxEvtHandler::ProcessEventLocally ([email protected]=0x61c000042880, event=...) at ../git/src/common/event.cpp:1526
#16 0x00007ffff29b832f in wxEvtHandler::ProcessEvent (this=0x61c000042880, event=...) at ../git/src/common/event.cpp:1499
#17 0x00007ffff369f425 in wxScrollHelperEvtHandler::ProcessEvent (this=0x608000579ca0, event=...) at ../git/src/generic/scrlwing.cpp:200
#18 0x00007ffff29b84d1 in wxEvtHandler::SafelyProcessEvent (this=<optimized out>, event=...) at ../git/src/common/event.cpp:1617
#19 0x00007ffff36273e6 in wxWindowBase::HandleWindowEvent ([email protected]=0x61c000042880, event=...) at ../git/src/common/wincmn.cpp:1539
#20 0x00007ffff33f6145 in wxWindow::GTKSendPaintEvents ([email protected]=0x61c000042880, region=<optimized out>) at ../git/src/gtk/window.cpp:5184
#21 0x00007ffff33f63b5 in expose_event (gdk_event=0x7fffffffd380, win=0x61c000042880) at ../git/src/gtk/window.cpp:432
#22 0x00007ffff6933b46 in _gtk_marshal_BOOLEAN__BOXED (closure=0x6070006c1580, return_value=0x7fffffffcfb0, n_param_values=<optimized out>, param_values=0x7fffffffd010, invocation_hint=<optimized out>, marshal_data=<optimized out>) at gtkmarshalers.c:84
#23 0x00007ffff517a325 in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0
#24 0x00007ffff518cc62 in ?? () from /usr/lib64/libgobject-2.0.so.0
#25 0x00007ffff51951d7 in g_signal_emit_valist () from /usr/lib64/libgobject-2.0.so.0
#26 0x00007ffff5195b1f in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0
#27 0x00007ffff6a5439c in gtk_widget_event_internal ([email protected]=0x621000c35b40, [email protected]=0x7fffffffd380) at /var/tmp/portage/x11-libs/gtk+-2.24.32-r1/work/gtk+-2.24.32/gtk/gtkwidget.c:5010
#28 0x00007ffff6a5474f in IA__gtk_widget_send_expose ([email protected]=0x621000c35b40, [email protected]=0x7fffffffd380) at /var/tmp/portage/x11-libs/gtk+-2.24.32-r1/work/gtk+-2.24.32/gtk/gtkwidget.c:4839
#29 0x00007ffff69328a2 in IA__gtk_main_do_event (event=0x7fffffffd380) at /var/tmp/portage/x11-libs/gtk+-2.24.32-r1/work/gtk+-2.24.32/gtk/gtkmain.c:1623
#30 0x00007ffff658b3c2 in _gdk_window_process_updates_recurse ([email protected]=0x6250007976c0, [email protected]=0x6190004aad60) at /var/tmp/portage/x11-libs/gtk+-2.24.32-r1/work/gtk+-2.24.32/gdk/gdkwindow.c:5479
#31 0x00007ffff658b365 in _gdk_window_process_updates_recurse ([email protected]=0x62500079a000, [email protected]=0x6190004b9d50) at /var/tmp/portage/x11-libs/gtk+-2.24.32-r1/work/gtk+-2.24.32/gdk/gdkwindow.c:5452
#32 0x00007ffff658b365 in _gdk_window_process_updates_recurse ([email protected]=0x625000797ea0, [email protected]=0x6190004cb0d0) at /var/tmp/portage/x11-libs/gtk+-2.24.32-r1/work/gtk+-2.24.32/gdk/gdkwindow.c:5452
#33 0x00007ffff658b365 in _gdk_window_process_updates_recurse ([email protected]=0x6250004efd80, [email protected]=0x61900047ab80) at /var/tmp/portage/x11-libs/gtk+-2.24.32-r1/work/gtk+-2.24.32/gdk/gdkwindow.c:5452
#34 0x00007ffff658b365 in _gdk_window_process_updates_recurse ([email protected]=0x6250004ef120, [email protected]=0x6190004d5090) at /var/tmp/portage/x11-libs/gtk+-2.24.32-r1/work/gtk+-2.24.32/gdk/gdkwindow.c:5452
#35 0x00007ffff65bbcda in _gdk_windowing_window_process_updates_recurse ([email protected]=0x6250004ef120, [email protected]=0x6190004d5090) at /var/tmp/portage/x11-libs/gtk+-2.24.32-r1/work/gtk+-2.24.32/gdk/x11/gdkwindow-x11.c:5643
#36 0x00007ffff6587d02 in gdk_window_process_updates_internal (window=0x6250004ef120) at /var/tmp/portage/x11-libs/gtk+-2.24.32-r1/work/gtk+-2.24.32/gdk/gdkwindow.c:5646
#37 0x00007ffff6588658 in IA__gdk_window_process_all_updates () at /var/tmp/portage/x11-libs/gtk+-2.24.32-r1/work/gtk+-2.24.32/gdk/gdkwindow.c:5752
#38 0x00007ffff65886b9 in gdk_window_update_idle (data=<optimized out>) at /var/tmp/portage/x11-libs/gtk+-2.24.32-r1/work/gtk+-2.24.32/gdk/gdkwindow.c:5372
#39 0x00007ffff6566499 in gdk_threads_dispatch (data=0x6190004cbb00) at /var/tmp/portage/x11-libs/gtk+-2.24.32-r1/work/gtk+-2.24.32/gdk/gdk.c:534
#40 0x00007ffff4e9a45a in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
#41 0x00007ffff4e9a818 in ?? () from /usr/lib64/libglib-2.0.so.0
#42 0x00007ffff4e9ab42 in g_main_loop_run () from /usr/lib64/libglib-2.0.so.0
#43 0x00007ffff6931612 in IA__gtk_main () at /var/tmp/portage/x11-libs/gtk+-2.24.32-r1/work/gtk+-2.24.32/gtk/gtkmain.c:1270
#44 0x00007ffff33c0633 in wxGUIEventLoop::DoRun (this=0x606000c01e20) at ../git/src/gtk/evtloop.cpp:64
#45 0x00007ffff285bfbe in wxEventLoopBase::Run (this=0x606000c01e20) at ../git/src/common/evtloopcmn.cpp:90
#46 0x00007ffff281df1e in wxAppConsoleBase::MainLoop (this=0x61a00001e680) at ../git/src/common/appbase.cpp:380
#47 0x00007ffff2819907 in wxAppConsoleBase::OnRun (this=<optimized out>) at ../git/src/common/appbase.cpp:301
#48 0x00007ffff34c3180 in wxAppBase::OnRun (this=<optimized out>) at ../git/src/common/appcmn.cpp:335
#49 0x00005555556b1f75 in CodeBlocksApp::OnRun (this=0x61a00001e680) at /home/obfuscated/projects/codeblocks/git/src/src/app.cpp:870
#50 0x00007ffff28b1cd6 in wxEntry ([email protected]: 8, argv=<optimized out>) at ../git/src/common/init.cpp:507
#51 0x00007ffff28b29e2 in wxEntry (argc=<optimized out>, argv=<optimized out>) at ../git/src/common/init.cpp:519
#52 0x00005555556ad7d9 in main (argc=8, argv=0x7fffffffde98) at /home/obfuscated/projects/codeblocks/git/src/src/app.cpp:338

It seems that svPGBitProp::GetChoiceSelection returns an index which is out-of-bounds for this case. :(
(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: 12123
    • Travis build status
Re: [New plugin] cbSystemView for embedded development
« Reply #7 on: January 06, 2019, 05:12:19 pm »
General notes about the source code:
1. Consider automatic solution for formatting your code
2. Switch to C++ 11 and use for-each style loops it will make your code more readable.
3. Do not use %lld or %llx for types other than long long, because this is not portable and leads to -Wformat warnings.
4. Do not use exceptions, I've seen at least one place where you were hiding a bug catching bad_something exception. The problem in this case is that you're erasing an iterator and then incrementing it. This is wrong use of the API.
5. Consider specifying -Werror=return-type
6. Consider using clang-tidy to specify override for all methods you already override.
(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: 12123
    • Travis build status
Re: [New plugin] cbSystemView for embedded development
« Reply #8 on: January 06, 2019, 06:05:24 pm »
BTW:
Is it expected that the plugin will display a progress dialog during memwatch update?
I have all registers expanded for my mcu and it is taking quite a lot to update them, but I don't see any progress dialog.

It seems that the performance of the x command depends on the requested size. If this is really the case (I've not tried to do some benchmarking) the plugin should have totally separate workflow.

For example I have a stm32f103c8t6 in a black pill. I'm using a st link v2 clone and swd interface. I see that I can look at registers for quite a lot of peripherals which I'll probably never use and for sure I'll never use them simultaneously. So I think the plugin should have a page where I could add registers (single registers, not group of registers) and then only those registers are updated.

Also I think the current mode of updating only the expanded registers is not really user friendly. Probably you could use the third column to add a checkbox or make a custom property which have a checkbox somewhere. This checkbox or special toggle bitmap button if possible should be used to specify if the register is autoupated or not.

And a bug report:
1. Expand all registers
2. Start a debug session
3. Collapse all registers while they are read. For me this should cancel the operation, but it doesn't, it just wastes time and then discards the data, because the next expand would re-execute the x commands.
(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: 2566
Re: [New plugin] cbSystemView for embedded development
« Reply #9 on: January 06, 2019, 06:22:51 pm »
Quote
Is it expected that the plugin will display a progress dialog during memwatch update?
Yes, for long operations it should display a update (wxProgress) dialog.
What operating system are you using?

Quote
It seems that the performance of the x command depends on the requested size. If this is really the case (I've not tried to do some benchmarking) the plugin should have totally separate workflow.
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)

Quote
For example I have a stm32f103c8t6 in a black pill. I'm using a st link v2 clone and swd interface. I see that I can look at registers for quite a lot of peripherals which I'll probably never use and for sure I'll never use them simultaneously. So I think the plugin should have a page where I could add registers (single registers, not group of registers) and then only those registers are updated.
I planned to ad a favorite tab where you can add your needed registers

Quote
Also I think the current mode of updating only the expanded registers is not really user friendly. Probably you could use the third column to add a checkbox or make a custom property which have a checkbox somewhere. This checkbox or special toggle bitmap button if possible should be used to specify if the register is autoupated or not.
see the above. I think the normal workflow should be to add them to your favorites...
Also (at least for me) the normal workflow is, that something is not working and you want to see what one specific register holds, so you search it with the search text box, expand it and look at the value. I do not think that you need all registers quite often, so updating all at once will take a long time (speed of SWD) and is not needed...

Quote
General notes about the source code:
Thank you, i will try to implement them as soon as i find time...

Quote
And a bug report:
would be nice if you could put them in github issue tracker...


Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12123
    • Travis build status
Re: [New plugin] cbSystemView for embedded development
« Reply #10 on: January 06, 2019, 06:53:53 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)
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.
(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: 2566
Re: [New plugin] cbSystemView for embedded development
« Reply #11 on: January 06, 2019, 07:15:55 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)
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.

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?
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 ;)

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12123
    • Travis build status
Re: [New plugin] cbSystemView for embedded development
« Reply #12 on: January 06, 2019, 08:40:23 pm »
Can you draw an image of your idea of the api? What do you mean by separate workflow?

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.

If it is possible it would be nice... But does GDB let you do it? What do you mean by "now" ?
"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.

If you work on this, you can also think about an api to send general commands to the debugger, something like a queue ;)
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.
(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: 2566
Re: [New plugin] cbSystemView for embedded development
« Reply #13 on: January 06, 2019, 09:05:05 pm »
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.
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)
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.
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.
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...




Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12123
    • Travis build status
Re: [New plugin] cbSystemView for embedded development
« Reply #14 on: January 06, 2019, 10:12:29 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....
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.

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...
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?
(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: 12123
    • 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: [Select]
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: 12123
    • 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: [Select]
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: 12123
    • 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: 2566
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: 2566
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: 12123
    • 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: 2566
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: [Select]
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: 12123
    • 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: 2566
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: 12123
    • 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: 2566
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: 2566
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: [Select]
codeblocks->codeblocks->arm_gdb->arm_gdb_serverworking:
Code: [Select]
codeblocks->arm_gdb->arm_gdb_serverthis 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: 12123
    • 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: 5247
  • 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: 12123
    • 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!]