Tested on commit: b813bdebb36501500e86fea5f7e15b4b15ea0902 Images tested: qemux86, qemux86-64 Image type: core-image-sato-sdk Steps to reproduce: 1. download image from http://autobuilder.yoctoproject.org/pub/releases/yocto-1.8M1/machines/qemu/qemux86/core-image-sato-sdk-qemux86.ext3 2. start qemu emulator using the image downloaded (will also require a kernel file and environment set-up) 3. once qemu boots up, open a new terminal window and issue command "opcontrol" Expected result: You should receive the opcontrol usage instructions. Observed result: "command not found" error message is issued. This impacts the "oprofile" linux tool in the Eclipse plugin, which now fails. I am unsure about the classification, though. This feels like it's an issue with qemu packages, but the only impact noted is for the Eclipse plugin, it seems.
The issue is that opcontrol was removed in the upstream oprofile project in favour of using perf instead. The UIs therefore need to adapt to the changes in oprofile, oprofile is still installed in the images.
The issue here is oprofileui is still using opcontrol and needs updating to use the perf inferface to control the data collection. This is problem something Tom or RP have the experience to resolve.
Changing the documentation to Undecided since the results displayed in OprofileUi might change with the new functionalities. This may imply changing the manual and/or the tracing&profiling wiki: https://wiki.yoctoproject.org/wiki/Tracing_and_Profiling
Looking at the changes, opcontrol is gone and we need to use operf. The difference is that operf remains running the whole time data is collected, the opcontrol script used to handle this for us. opserver therefore likely needs to use g_spawn_async instead of g_spawn_sync and the config command needs to just save data into the server. The ideal case of being able to quickly turn on/off profiling with low overhead (e.g. with a signal) no longer seems possible.
found during 1.8_M4.rc2 testing fido:33558eacc8a2d3dce3396b9ab2fd0773ac5076bc
For future reference, RP started hacking some fixes at http://www.rpsys.net/oprofileui.patch before realising just how much work is needed.
Propose to defer this to M2.
seems that the issue still exists in YP 2.1_M2.rc1 master/3d2c0f5902cacf9d8544bf263b51ef0dd1a7218c
Porting and updating oprofileui is likely wasted time. sysprof has been taken over by the GNOME Builder maintainer (Christian Herbert) so should have a good future and shouldn't need too much engineering to support some sort of remote connection model. Alternatively, we could test and support the perf support in Eclipse, if that has remote support (or write it if required). Tim has been talking to the Eclipse people so I've CCd him for his opinion.
Thanks for the reminder to test oprofile and other Linux Tools. Especially the remote parts :) I am establishing good connections in the community, so if we need to upstream patches I expect to find a workable solution.
Tim, did you get anywhere with oprofile? Also, does anyone currently have a good summary of the situation in 2017? * is this still an issue we need to solve? * is eclipse relevant or should I touch base with gnome-builder folks?
We have restarted working on a plugin crops/eclipse-crops to allow building and qemu in containers. Haven't dealt with profiling yet.
Reassigning Jussi's bugs.
eclipse has been dropped.
closing