Community
Participate
Working Groups
Build Identifier: While looking what functions I used in common in the Perf plugin that should be moved to the profiling framework I realised the respective common functions had already been moved/implemented there- the OProfile plugin just hadn't changed to be using it yet. Changing this inheritance covers most of it- the exec() function in AbstractOprofile.. should be removed and references swapped to execute() in ProfileLaunch.. =) Reproducible: Always
Created attachment 173805 [details] patch attempt Did you envision something like this?
Created attachment 173806 [details] mylyn/context/zip
Charley, do you know whatthe generateCommand implementations should be?
(In reply to comment #3) > Charley, do you know whatthe generateCommand implementations should be? The Profile Framework's launch process works by creating and launching a script in /tmp: #!/bin/sh exec __COMMAND__ __COMMAND__ is filled by the return value of generateCommand, and should contain the command as it would appear on the commandline. e.g. for SystemTap, we return: stap -o /output/path -c '/binary/path' /script/path.stp /binary/path
Further detail: I can take a look at having OProfile use ProfileLaunchConfiguraitonDelegate#createProcess, which would make use of the generateCommand function. From a quick glance, I think the difference is that createProcess launches a system process and returns an IProcess with streams that can be monitored, while execute just launches a system process. For OProfile this does not appear to be necessary. I will investigate further.
Tested Andrew's patch, it works :) No real benefits to using createProcess here, but this section of API could perhaps be better documented
Personally when I swapped my Perf implementation (which was originally based on OProfile) to the one in the profiling framework, I didn't make use of generateCommand or createProcess here, the previous method is better suited I think =)
The patch looks fine to me. As long as createProcess isn't used, there's no reason to implement generateCommand.
Please apply as you see fit, Roland.
Revision #25325
Resolving.
