[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Local C/C++ Application Launch and Linux Tools Profiling
|
I have created an RFE:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=391608 for this.
-- Jeff J.
On 10/02/2012 03:49 PM, Jeff Johnston wrote:
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.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
