Re: [linuxtools-dev] oprofile on remote targets

[Anna Dushistova <anna_dushistova@xxxxxxxxxx>]

Hi All,
may I ask why cannot this be done in a transport-agnostic way via RSE
just like we do for remote launching/debugging in org.eclipse.cdt.launch.remote?

Just curious.

Thanks!
Anna.

On Jun 10, 2011, at 10:21 PM, Siva Velusamy wrote:

> Hi,
> 
> We'd like to include the oprofile plugins in an Eclipse based SDK that we ship. However, we need to add support for remote targets in oprofile since our focus is primarily on embedded targets. Browsing through the archives, I see that a number of people have requested this feature, but I'm not sure if someone is actively working on it. I plan to work on it over the next couple of weeks, but I thought I'd get some feedback before I start. I've summarized my understanding of the current status, and what might be required to adapt the current sources for supporting remote targets. I'd appreciate it if you could provide some feedback on the proposal.
> 
> Current Status:
> 
> 1. There is an existing contribution (in bugzilla) from ST that does support remote targets. However, this contribution works in a very different way than the Linuxtools oprofile plugins. In particular, it directly parses the oparchive files, and as a result is very dependent on the oprofile version. In my tests, it doesn't work with the oparchive from oprofile 0.9.6. The code in bugzilla might be out of date though. One nice thing about this approach is that the views are similar to gprof, and it is nice to have some consistency.
> 
> 2. The Linuxtools oprofile plugins don't have support for remote targets, but the entire UI seems to operate out of the results from opxml. As a result, it should be possible to support remote targets by providing a way to launch oprofile on the target, and transferring the XML files from the target back to the host.
> 
> Since I'm not too fond of parsing oparchive, I think it is easier to modify the existing plugins than the ST plugin.
> 
> Proposed Changes:
> 
> At a high level, the current flow looks like this:
> 
>       oprofileShutdown();
>       oprofileReset();
>       oprofileSetupDaemon();
>       oprofileStartCollection();
> 
>       DebugPlugin.newProcess();
>       
>       oprofileDumpSamples();
>       oprofileShutdown();
>       
>       OpModelRoot.refreshModel()
>       UiModelRoot.refreshModel()
> 
> The current code already abstracts away all the oprofile launching into IOpcontrolProvider, and all the reading back of the XML into IOpxmlProvider. So in theory, we need remote implementations for 3 functions:
> 
> 1. IOpcontrolProvider
> 2. IOpxmlProvider
> 3. Ability to launch remote processes.
> 
> Since the target is anyways Linux, we should be able to reuse (or refactor) most of the code from LinuxOpxmlProvider.
> 
> The specific questions I have are:
> 
> 1. Am I overlooking something significant?
> 2. Am I correct in assuming that the OpModelRoot and UiModelRoot will not need any changes?
> 3. I also think that this should work fine on a Windows host, as long as the binary is compiled on Windows (and debug symbols in the binary can be mapped back to source).
> 4. I was initially thinking of a custom framework to communicate to the target, but a few recent threads on this list seem to indicate that this should be done using TCF. I haven't used TCF before - if someone could confirm that TCF is appropriate for this use case, that'll be greatly appreciated.
> 5. I'm going to ignore all discussions regarding PolicyKit etc initially. I assume that these proposed changes shouldn't significantly impact future support for that.
> 
> Thank you for your feedback. I have initiated some discussions with our legal team to make sure that we can contribute these changes back. If someone is already working on this, please do chime in.
> 
> /Siva
> _______________________________________________
> linuxtools-dev mailing list
> linuxtools-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/linuxtools-dev