Author Topic: Question on cbSystemView - an SVD plugin  (Read 29704 times)

Offline jimbo

  • Multiple posting newcomer
  • *
  • Posts: 55
Question on cbSystemView - an SVD plugin
« on: September 26, 2018, 12:33:15 pm »
Hi all,

Been looking at this plugin to display SVD information. Have a question, since I believe the author (BlueHazzard) is present on this forum.

I see from the readme that there is a specific branch recomended, but that recomendation was from a year ago, and I was wondering if the 17.12 version of CB (or a more recent branch from the upstream repo) has the required changes or whether I still need to use the non-upstream repo and branch. I'll be taking a look to see if I can determine this from commits, but would appreciate official advice!

Edit: What's the best way to get the latest source for CB? I see that obfuscated has a git clone of the subversion repo from SF and since I prefer git (ages since I used subversion) is that a good approach to use, or should I just use the SF SVN repo?

Regards

Jimbo

« Last Edit: September 26, 2018, 12:37:58 pm by jimbo »

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 3352
Re: Question on cbSystemView - an SVD plugin
« Reply #1 on: September 26, 2018, 01:02:09 pm »
No, the special branch is still needed, but i have not updated it since a while. I will try to bring it to a more bleeding edge state.

There are some tickets in the tracker to bringing the functionality to codeblocks trunk:
https://sourceforge.net/p/codeblocks/tickets/619/ and
https://sourceforge.net/p/codeblocks/tickets/543/

Offline jimbo

  • Multiple posting newcomer
  • *
  • Posts: 55
Re: Question on cbSystemView - an SVD plugin
« Reply #2 on: September 26, 2018, 04:04:10 pm »
Thanks.

SVD support is a requirement for our proposed embedded microcontroller system, so having a standard plugin that works on a standard IDE is important. What are your expectations on this? Hopeful it will make it to the next CB release?

Jimbo

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13406
    • Travis build status
Re: Question on cbSystemView - an SVD plugin
« Reply #3 on: September 26, 2018, 06:04:00 pm »
The memory watches stuff would probably be added to code::blocks, the pause related stuff probably won't and another mechanism should be used. Not sure when I'll find the time to review and push this stuff to trunk. :(
(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 jimbo

  • Multiple posting newcomer
  • *
  • Posts: 55
Re: Question on cbSystemView - an SVD plugin
« Reply #4 on: September 27, 2018, 04:56:02 pm »
No, the special branch is still needed, but i have not updated it since a while. I will try to bring it to a more bleeding edge state.

There are some tickets in the tracker to bringing the functionality to codeblocks trunk:
https://sourceforge.net/p/codeblocks/tickets/619/ and
https://sourceforge.net/p/codeblocks/tickets/543/

Struggling to get this working. Have built the required branch and plugin. I did need to comment out a line referencing cbEVT_DEBUGGER_CONTINUED, which makes me think the build isn't quite right, but I have set up the cb global to the correct directory on the special branch, so not sure where I have made a mistake.

I use --prefix on the configure to set up the new C::B in a local directory and run it from there, I'm wondering if thats the correct way of running a new build without overwriting the current installation. I do get some errors on startup which again makes me think either I am building it or running it incorrectly.

Get loads of errors on C::B startup once pluging installed, mostly unable to insert items in to a task bar, then it all dies.

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 3352
Re: Question on cbSystemView - an SVD plugin
« Reply #5 on: September 27, 2018, 06:16:51 pm »
The best way to build codeblocks for this purpose is to build it with codeblocks ;)
On my changes i update only the project files but not the make files, so if i have changed something in codeblocks it will probably break the make build system.

To build codeblocks, with codeblocks on linux open your codeblocks, and open the codeblocks_wx30_unix project file or workspace file.
You should be able to simply hit build and all should work.
Prior to starting the first time you have to run the "update30" script in the codeblocks source folder. This will copy all needed images and plugins ecc. This has only to be done one time.

If you want to run the new codeblocks outside codeblocks you have to run first the update30 script and then you can start codeblocks from the output30 folder with the run.sh script

Quote
Struggling to get this working. Have built the required branch and plugin. I did need to comment out a line referencing cbEVT_DEBUGGER_CONTINUED, which makes me think the build isn't quite right, but I have set up the cb global to the correct directory on the special branch, so not sure where I have made a mistake.
are you building this branch: https://github.com/bluehazzard/codeblocks_sf/tree/debugger/pull_candidate/memory_range_watch/1 ?
If so build logs are needed to help you...

Quote
Get loads of errors on C::B startup once pluging installed, mostly unable to insert items in to a task bar, then it all dies.
This is probably because you have not run the update script... Or you messed the wxWidgets library versions..

Offline jimbo

  • Multiple posting newcomer
  • *
  • Posts: 55
Re: Question on cbSystemView - an SVD plugin
« Reply #6 on: September 28, 2018, 11:33:47 am »
The best way to build codeblocks for this purpose is to build it with codeblocks ;)
On my changes i update only the project files but not the make files, so if i have changed something in codeblocks it will probably break the make build system.

To build codeblocks, with codeblocks on linux open your codeblocks, and open the codeblocks_wx30_unix project file or workspace file.
You should be able to simply hit build and all should work.
Prior to starting the first time you have to run the "update30" script in the codeblocks source folder. This will copy all needed images and plugins ecc. This has only to be done one time.

If you want to run the new codeblocks outside codeblocks you have to run first the update30 script and then you can start codeblocks from the output30 folder with the run.sh script

Quote
Struggling to get this working. Have built the required branch and plugin. I did need to comment out a line referencing cbEVT_DEBUGGER_CONTINUED, which makes me think the build isn't quite right, but I have set up the cb global to the correct directory on the special branch, so not sure where I have made a mistake.
are you building this branch: https://github.com/bluehazzard/codeblocks_sf/tree/debugger/pull_candidate/memory_range_watch/1 ?
If so build logs are needed to help you...

Quote
Get loads of errors on C::B startup once pluging installed, mostly unable to insert items in to a task bar, then it all dies.
This is probably because you have not run the update script... Or you messed the wxWidgets library versions..

Cool, thanks for the detailed info. Will give it a go now!

Offline jimbo

  • Multiple posting newcomer
  • *
  • Posts: 55
Re: Question on cbSystemView - an SVD plugin
« Reply #7 on: November 23, 2018, 11:47:41 am »
OK, finally got time to get back on this.

Been looking at the changes made to underlying CB code to implement this plugin, and just need a quick understanding of what is needed. AIUI, there are two sets of changes, one to provide memory watch ranges, and one that provides some sort of event/message from debugger to the plugin. I presume this second is so the plugin can be informed that something has changed and it therefor needs to update its display? However, also AIUI, this event system change is not going to be accepted, whilst the memory range stuff is likely to be?

From my POV, for an interim solution, a button on the plugin to refresh the GUI would be fine until whatever new 'event' system is in place, so would this be a feasible approach? It requires the memory range changes, which just need to be code reviewed, plus a minor change to the plugin to add abutton  for refresh instead of having it happen automatically?

I'll have a go at pulling in the patches for the memory watch stuff, then play around with the plugin button stuff, to see if this does the job, but any comments in the meantime welcomed.

Edit: patches 0004 to 0010 applied OK, 0011 won't apply, so just sorting that out.




« Last Edit: November 23, 2018, 05:03:12 pm by jimbo »

Offline jimbo

  • Multiple posting newcomer
  • *
  • Posts: 55
Re: Question on cbSystemView - an SVD plugin
« Reply #8 on: November 26, 2018, 04:53:54 pm »
Keep getting seg faults with this plugin as it stands, running from a recent nightly.

Problem is that now Codeblocks segs faults on startup, and I need to know how to disable this plugin from running , so what does Codeblocks do when you install a plugin? Does it move it to a new location,  and have some sort of database files to refenrece? Or similar? Where are these config files so I can manually edit and disble the plugin so I can get codeblocks to restart. Been googling and grepping tmy filesystem looking for stuff, but not found anything.

Note I am using a home build codeblocks, running it from src/src/.lib, which could well be part of the problem.

Running Lubuntu.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13406
    • Travis build status
Re: Question on cbSystemView - an SVD plugin
« Reply #9 on: November 26, 2018, 05:36:26 pm »
Find the .so file for the plugin and remove it. This is the most straight forward way. Probably try if running in safe mode work. --help for the exact flag.
(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 jimbo

  • Multiple posting newcomer
  • *
  • Posts: 55
Re: Question on cbSystemView - an SVD plugin
« Reply #10 on: November 26, 2018, 05:39:21 pm »
Keep getting seg faults with this plugin as it stands, running from a recent nightly.

Problem is that now Codeblocks segs faults on startup, and I need to know how to disable this plugin from running , so what does Codeblocks do when you install a plugin? Does it move it to a new location,  and have some sort of database files to refenrece? Or similar? Where are these config files so I can manually edit and disble the plugin so I can get codeblocks to restart. Been googling and grepping tmy filesystem looking for stuff, but not found anything.

Note I am using a home build codeblocks, running it from src/src/.lib, which could well be part of the problem.

Running Lubuntu.

What I think has happened is that this SVD plugin has somehow broken the debugger toolbar in the system itself, because the calls stack shows a problem in the debugger, rather than in the cbSystemView plugin itself (and after starting ins safe mode, the cbSystem view plugin is not actually installed). Any ideas how I recover this?

Code
#0  0x00007ffff4fe79cf in std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::_M_replace(unsigned long, unsigned long, wchar_t const*, unsigned long) ()
    at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x00007fffc69152de in DebuggerGDB::GetCurrentPosition(wxString&, int&) () at /usr/local/lib/codeblocks/plugins/libdebugger.so
#2  0x000055555562e3e3 in DebuggerToolbarHandler::OnUpdateUI(wxUpdateUIEvent&) (this=0x5555561b1f90, event=...) at debuggermenu.cpp:822
#3  0x00007ffff56394be in wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#4  0x00007ffff56395c3 in wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#5  0x00007ffff563998b in wxEvtHandler::TryHereOnly(wxEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#6  0x00007ffff5639783 in wxEvtHandler::DoTryChain(wxEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#7  0x00007ffff5639a75 in wxEvtHandler::ProcessEvent(wxEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#8  0x00007ffff5f6918b in wxWindowBase::TryAfter(wxEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
#9  0x00007ffff5f4f7b0 in wxToolBarBase::UpdateWindowUI(long) () at /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
#10 0x00007ffff5f6a713 in wxWindowBase::SendIdleEvents(wxIdleEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
#11 0x00007ffff5f6a748 in wxWindowBase::SendIdleEvents(wxIdleEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
#12 0x00007ffff5dff60f in wxFrame::SendIdleEvents(wxIdleEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
#13 0x00007ffff5e40dbd in wxAppBase::ProcessIdle() () at /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
#14 0x00007ffff5d66bc9 in wxApp::DoIdle() () at /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
#15 0x00007ffff5d66cc3 in  () at /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
#16 0x00007ffff402d1f5 in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#17 0x00007ffff402d5c0 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#18 0x00007ffff402d8d2 in g_main_loop_run () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#19 0x00007ffff3acea37 in gtk_main () at /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#20 0x00007ffff5d86b05 in wxGUIEventLoop::DoRun() () at /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
#21 0x00007ffff54f5a93 in wxEventLoopBase::Run() () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#22 0x00007ffff54bd0a6 in wxAppConsoleBase::MainLoop() () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#23 0x000055555560600e in CodeBlocksApp::OnRun() (this=0x555555a5a4a0) at app.cpp:870
#24 0x00007ffff5547ae9 in wxEntry(int&, wchar_t**) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#25 0x000055555560341f in main(int, char**) (argc=1, argv=0x7fffffffdf58) at app.cpp:338

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13406
    • Travis build status
Re: Question on cbSystemView - an SVD plugin
« Reply #11 on: November 26, 2018, 05:55:43 pm »
What do you mean by recover?
(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 jimbo

  • Multiple posting newcomer
  • *
  • Posts: 55
Re: Question on cbSystemView - an SVD plugin
« Reply #12 on: November 26, 2018, 06:14:03 pm »
By recover I mean get it back to a state where codeblocks will start up again.

In fact, I got to the state by sudo make install

WHich actually showed up what I was doing wrong - becaue i was running codeblock from ./src/sr/.lib for some reason when I sinstalled the plugin it was not getting copied to the /usr/local/libs/codeblocks/plugins folder, which meant that some resources were not being loaded correctly from the zip ile as it coudlnt find. it.

The plugin still isn't starting up for some reason, but at least the crashing has stopped for the moment as I am now running the codeblocks that is installed by sudo make install. I feel sure there is a better way of doing dev work on plugins and codeblocks at the same time...

Just getting this on the command line.

Code
Initializing plugins...
KeyBinder failed UpdateById on[2384][cbSystemView...]
KeyBinder failed UpdateById on[923][Window]
Loading menubar...
Editor Tweaks plugin: Building menu
Editor Tweaks plugin: making the menu 15
Editor Tweaks plugin: Folding menu
Loading menubar...
Editor Tweaks plugin: Building menu
Editor Tweaks plugin: making the menu 15
Editor Tweaks plugin: Folding menu
Failed
Failed

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13406
    • Travis build status
Re: Question on cbSystemView - an SVD plugin
« Reply #13 on: November 26, 2018, 06:53:57 pm »
Something is wrong with your install. Probably C::B is loading plugins from two places and in both of them you have the same plugins.

If you've not passed a non-default prefix to configure it is a good idea to do so. It will make it a lot easier to clean up your install and start over.
(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: 3352
Re: Question on cbSystemView - an SVD plugin
« Reply #14 on: November 26, 2018, 10:36:31 pm »
Quote
Edit: patches 0004 to 0010 applied OK, 0011 won't apply, so just sorting that out.
That should be ok, because the last patch is only for setting values, so as long you do not set a value in the svd plugin everything should work

Quote
From my POV, for an interim solution, a button on the plugin to refresh the GUI would be fine until whatever new 'event' system is in place, so would this be a feasible approach? It requires the memory range changes, which just need to be code reviewed, plus a minor change to the plugin to add abutton  for refresh instead of having it happen automatically?
I do not think that a button is a bad idea... Just add a poll timer that updates the memory watches every 1 sek or so and check for the modified flag in the watch.

Quote
Keep getting seg faults with this plugin as it stands, running from a recent nightly.
Ofc this would not work with the current nightly. Why not try my branch on github?

Quote
What I think has happened is that this SVD plugin has somehow broken the debugger toolbar in the system itself,
nope, i does not modify the toolbar...
One try to find what is going wrong you can start codeblocks trough gdb
Code
gdb codeblocks

Quote
By recover I mean get it back to a state where codeblocks will start up again.
As obfuscated said, search for the .so file of the plugin and delete it...

Quote
If you've not passed a non-default prefix to configure it is a good idea to do so. It will make it a lot easier to clean up your install and start over.
This is so important... why do we not use the /opt/ directory as default target? This would help a lot beginners to clean up everything...

Also you would not have this problem if you build codeblocks with codeblocks ;)