Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
[New plugin] cbSystemView for embedded development
BlueHazzard:
--- 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?
--- End quote ---
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.
--- End quote ---
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.
oBFusCATed:
I'm getting crashes if I expand a register which the debugger cannot access.
--- Code: ---#0 0x00007ffff442dd94 in wxPGChoicesData::Item (this=0x0, i=0) at ../git/include/wx/propgrid/property.h:673
#1 0x00007ffff442deae in wxPGChoices::Item (this=this@entry=0x61600172bdb8, i=i@entry=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 (this=this@entry=0x61600172bc80, column=column@entry=1, choiceIndex=choiceIndex@entry=0, flags=flags@entry=0, pString=pString@entry=0x7fffffffc580, pCell=pCell@entry=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 (this=this@entry=0x61c000042880, dc=..., itemsRect=itemsRect@entry=0x7fffffffcac0, isBuffered=isBuffered@entry=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 (this=this@entry=0x61c000042880, dc=..., topItemY=<optimized out>, bottomItemY=<optimized out>, itemsRect=itemsRect@entry=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=..., handler=handler@entry=0x61c000042880, event=...) at ../git/src/common/event.cpp:1396
#12 0x00007ffff29b814f in wxEventHashTable::HandleEvent (this=<optimized out>, event=..., self=self@entry=0x61c000042880) at ../git/src/common/event.cpp:1004
#13 0x00007ffff29b81fa in wxEvtHandler::TryHereOnly (this=this@entry=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 (this=this@entry=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 (this=this@entry=0x61c000042880, event=...) at ../git/src/common/wincmn.cpp:1539
#20 0x00007ffff33f6145 in wxWindow::GTKSendPaintEvents (this=this@entry=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 (widget=widget@entry=0x621000c35b40, event=event@entry=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 (widget=widget@entry=0x621000c35b40, event=event@entry=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 (window=window@entry=0x6250007976c0, expose_region=expose_region@entry=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 (window=window@entry=0x62500079a000, expose_region=expose_region@entry=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 (window=window@entry=0x625000797ea0, expose_region=expose_region@entry=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 (window=window@entry=0x6250004efd80, expose_region=expose_region@entry=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 (window=window@entry=0x6250004ef120, expose_region=expose_region@entry=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 (window=window@entry=0x6250004ef120, region=region@entry=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 (argc=@0x7ffff2c51c30: 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
--- End code ---
It seems that svPGBitProp::GetChoiceSelection returns an index which is out-of-bounds for this case. :(
oBFusCATed:
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.
oBFusCATed:
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.
BlueHazzard:
--- Quote ---Is it expected that the plugin will display a progress dialog during memwatch update?
--- End quote ---
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.
--- End quote ---
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.
--- End quote ---
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.
--- End quote ---
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:
--- End quote ---
Thank you, i will try to implement them as soon as i find time...
--- Quote ---And a bug report:
--- End quote ---
would be nice if you could put them in github issue tracker...
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version