Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cdt-dev] Local C/C++ Application Launch and Linux Tools Profiling

I'd like to start a conversation with the CDT debug/launch maintainers regarding profiling.

At present, Linux Tools creates a set of Launch short-cuts that support various profiling tools. As such, they all appear under the Profile As... menu per the Launch short-cut framework. For example, there is a Profile with Valgrind (which uses memcheck) and a Profile with OProfile.

We are currently under way unifying our own profiling framework to group tools into categories such as Profile Memory, Profile Timing, and Profile Coverage whereby the user would get a default tool selected for them and they don't need to have detailed knowledge regarding the various tools. The user still has the ability to change which tool is the default for any category (e.g. they could select using Memory Usage via Valgrind Massif instead of Memory Checking via Valgrind Memcheck) and can set tool options in the case where they are experienced users.

In truth, the short-cuts we are creating are really for a Local C/C++ Application and it doesn't make sense to add them all to the Profile as.. menu. The menu wording sequence also doesn't make sense: e.g. Profile as..->Profile with Valgrind. We should be instead providing a single short-cut: Profile as..->Local C/C++ Application to be consistent with the current CDT Run as.. and Debug as.. short-cuts and so that the menu selection makes sense.

It would be beneficial to allow the user to set common parameters among Run as.., Debug as.., and Profile as...

I would like to propose for Kepler that the CDT Launch short-cut: "org.eclipse.cdt.debug.ui.localCShortcut" add a profile mode.

To handle the low-level profiling support, I propose a new CDT extension that would specify a CDT Profile proxy provider. The id for the profile provider could be constructed based on an existing CDT id (e.g. the launch type id) so that it would be relatively easy for CDT to find the appropriate extension to use.

The Local Application profiling support could proxy off a few items such as additional tabs and the actual delegate to use. In the case of Linux Tools, there would be a single tab which would allow setting of the profiling category and the appropriate tool. Third-party tools can be added easily to the Linux Tool profiling framework in the future. By default, profiling would use Perf (if the plug-in is installed) which provides timing information and does not require any set-up or root access to use.

Ideally, I would like to be able to suppress gdb references in the tabs when the mode is profile since gdb won't be used, but I would not want to disrupt current Run and Debug behaviour.

As mentioned, the CDT Local C/C++ application profiling delegate would punt to the delegate from the extension to perform the execution and profiling via whatever tools are specified in the tabs and preferences.

Using such an extension, the CDT would not have any requirements on Linux Tools.

In the case where the profiling provider is not found, the code could default to add a default Profiling tab which simply notes there are no profiling providers installed and the regular Run delegate would be used.

Thoughts?  Issues?

-- Jeff J.

Back to the top