Code::Blocks Forums

User forums => Embedded development => Topic started by: jimbo on September 26, 2018, 12:33:15 pm

Title: Question on cbSystemView - an SVD plugin
Post by: jimbo 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

Title: Re: Question on cbSystemView - an SVD plugin
Post by: BlueHazzard 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/
Title: Re: Question on cbSystemView - an SVD plugin
Post by: jimbo 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
Title: Re: Question on cbSystemView - an SVD plugin
Post by: oBFusCATed 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. :(
Title: Re: Question on cbSystemView - an SVD plugin
Post by: jimbo 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.
Title: Re: Question on cbSystemView - an SVD plugin
Post by: BlueHazzard 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..
Title: Re: Question on cbSystemView - an SVD plugin
Post by: jimbo 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!
Title: Re: Question on cbSystemView - an SVD plugin
Post by: jimbo 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.




Title: Re: Question on cbSystemView - an SVD plugin
Post by: jimbo 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.
Title: Re: Question on cbSystemView - an SVD plugin
Post by: oBFusCATed 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.
Title: Re: Question on cbSystemView - an SVD plugin
Post by: jimbo 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
Title: Re: Question on cbSystemView - an SVD plugin
Post by: oBFusCATed on November 26, 2018, 05:55:43 pm
What do you mean by recover?
Title: Re: Question on cbSystemView - an SVD plugin
Post by: jimbo 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
Title: Re: Question on cbSystemView - an SVD plugin
Post by: oBFusCATed 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.
Title: Re: Question on cbSystemView - an SVD plugin
Post by: BlueHazzard 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 ;)

Title: Re: Question on cbSystemView - an SVD plugin
Post by: jimbo on November 27, 2018, 10:54:09 am
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.

OK, will rebuild with a different prefix, sounds like that should keepo the test versions away from the standard install?

Thanks.
Title: Re: Question on cbSystemView - an SVD plugin
Post by: oBFusCATed on November 27, 2018, 10:57:21 am
Yes, if you mix them you'll suffer quite a bit. Also it is possible to build codeblocks with codeblocks and also it is possible to setup the external plugin to also work with this version.
Title: Re: Question on cbSystemView - an SVD plugin
Post by: jimbo on November 27, 2018, 04:48:56 pm
Thanks, the prefix hint has helped enormously.

I now have the plugin sort of working in a recent nightly. Getting some seg faults in some places due to lack of error checking, so have added that.

Quick generic question about plugins and the dev cycle though since I am now at the point of altering the plugin code.

I am building the plugin in codeblocks itself, this results in a directory containng the cbplugin file and the zip file. This is where I originally installe the plugin from. On a rebuild of the plugin, where should I copy those to to update the code blocks installation (which I have in a directory in my home directory as specified by --prefix). When the plugin was originally installed it must have copied the zip file to ~/codeblocks_install/share/codeblocks, but I do not know what it did with the matching cbplugin file? Or indeed its contents. Currently reading the plugin docs to try and find the best procedure for development here.
Title: Re: Question on cbSystemView - an SVD plugin
Post by: BlueHazzard on November 27, 2018, 04:54:09 pm
There should be a target called "to_codeblocks" there the plugin will get installed automatically to codeblocks. The ".cbplugin" file is an archive that can be installed via Plugins->Plugin manager->install
Title: Re: Question on cbSystemView - an SVD plugin
Post by: jimbo on November 27, 2018, 05:14:41 pm
Ah Ha, presumably I need to alter the post build step to zip up to my specific codeblocks directory (as per --prefix)?]

EDIT: Ah, no, its uses the (#cb) thinkg to find it! Cool! thanks.

EDIT2: But there does seem to be an extra devel30 in there....remove?
Title: Re: Question on cbSystemView - an SVD plugin
Post by: BlueHazzard on November 27, 2018, 05:23:43 pm
Quote
EDIT2: But there does seem to be an extra devel30 in there....remove?
if you use the ./configure make install way then yes...
I use the codeblocks way, then devel30 is correct...
Title: Re: Question on cbSystemView - an SVD plugin
Post by: jimbo on November 27, 2018, 07:50:43 pm
Started to get the hang, but have had this codeblocks crash, which I suspect is unconnected with the plugin.

Code
[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
codeblocks: ../../src/xcb_io.c:259: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.

Should I report it elsewhere, the tracker?
Title: Re: Question on cbSystemView - an SVD plugin
Post by: jimbo on November 27, 2018, 08:10:34 pm
Quote
EDIT2: But there does seem to be an extra devel30 in there....remove?
if you use the ./configure make install way then yes...
I use the codeblocks way, then devel30 is correct...

Quick question for @Bluehazzard.

Whilst reading through the plugin code, come across a class, svPGPeripheryProp. The naming didn't seem to make much sense to me, but I wonder if you mean Peripheral as that would make more sense. Happy to make changes if that is the case - see next sentence!

Would you object to me making changes to this code, then submitting to your github as PR's for code review? One thing I have already done is run it through `astyle` to make it conform more closely to the Codeblocks coding standard.
Title: Re: Question on cbSystemView - an SVD plugin
Post by: BlueHazzard on November 27, 2018, 11:32:17 pm
Quote
hilst reading through the plugin code, come across a class, svPGPeripheryProp
the idea of the name was:
Code
sv........... for System Viewer (plugin name)
PG .......... for Property Grid, so it has something to do with the property grid part of the code
Periphery ... for the Periphery in the hardware, like ADC module, or I/O module. I do not know if this is correct english, but i think so...
Prop ........ for PROPerty. A property is a entry in the property grid that gives data, provides controls ecc.

Quote
Would you object to me making changes to this code, then submitting to your github as PR's for code review? One thing I have already done is run it through `astyle` to make it conform more closely to the Codeblocks coding standard.
Ofc, i would be happy if there are any improvements. Sadly i am a bit busy the next weeks but i will try to find some time... Just try to split them in small changes per commit..
Title: Re: Question on cbSystemView - an SVD plugin
Post by: BlueHazzard on November 27, 2018, 11:36:20 pm
Started to get the hang, but have had this codeblocks crash, which I suspect is unconnected with the plugin.

Code
[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
codeblocks: ../../src/xcb_io.c:259: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.

Should I report it elsewhere, the tracker?

This seems quite strange... Does the whole desktop environment hangs? Have you tried to deactivate the file browser plugin?
Title: Re: Question on cbSystemView - an SVD plugin
Post by: jimbo on November 28, 2018, 11:18:36 am
Started to get the hang, but have had this codeblocks crash, which I suspect is unconnected with the plugin.

Code
[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
codeblocks: ../../src/xcb_io.c:259: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.

Should I report it elsewhere, the tracker?

This seems quite strange... Does the whole desktop environment hangs? Have you tried to deactivate the file browser plugin?

It actually crashed out to the desktop rather than hanging, but this is a debug build, which probably makes behaviour change under these circumstances.
Title: Re: Question on cbSystemView - an SVD plugin
Post by: oBFusCATed on November 28, 2018, 11:30:43 am
If this is repeatable, please start codeblocks under gdb and post a backtrace.
Title: Re: Question on cbSystemView - an SVD plugin
Post by: jimbo on November 28, 2018, 11:48:47 am
Quote
hilst reading through the plugin code, come across a class, svPGPeripheryProp
the idea of the name was:
Code
sv........... for System Viewer (plugin name)
PG .......... for Property Grid, so it has something to do with the property grid part of the code
Periphery ... for the Periphery in the hardware, like ADC module, or I/O module. I do not know if this is correct english, but i think so...
Prop ........ for PROPerty. A property is a entry in the property grid that gives data, provides controls ecc.

In English, devices like ADC's are called peripherals, because they are on the periphery (around the outside) of the system. So I reckon it could be either in this case.

Quote
Quote
Would you object to me making changes to this code, then submitting to your github as PR's for code review? One thing I have already done is run it through `astyle` to make it conform more closely to the Codeblocks coding standard.
Ofc, i would be happy if there are any improvements. Sadly i am a bit busy the next weeks but i will try to find some time... Just try to split them in small changes per commit..

Will do.