[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [linuxtools-dev] Gcov and Gprof plugins
|
Gprof and gcov get their data just by running the executable that has
been compiled and linked with special compiler options.
Valgrind and Oprofile have executables that must run (Valgind itself and
opcontrol).
The plug-ins were written by separate developers so I would call the
difference a product of necessity. The gprof/gcov developer
took advantage of the fact that running the executable was already
supported and chose to focus on parsing and displaying the output data.
As part of profiling unification, it would make sense to have gprof and
gcov launchers that ran the executable. For remote, this would be
done remotely and the data acquired much like remote Valgrind does.
A special dialog could be displayed if no output data files are found and
instructions on how to compile the executable could be given: e.g.
Autotools
projects now have special options in configure settings to support both
gprof
and gcov.
-- Jeff J.
On 06/18/2012 03:33 PM, Renato Stoffalette Joao wrote:
Hi guys.
I have been trying to work on a remote implementation for Gcov and Gprof
plugins but I have some doubts I'd like to clarify.
Why do Gprof and Gcov plugins parse the (gmon.out,*.gcda,*.gcno) files
directly instead of running a "Process" like Valgrind and Oprofile do,
for instance ?
Are there advantages/disadvantages of running the plugins that way
instead of calling the binaries from OS with the command line
arguments ?
Thanks
Renato
_______________________________________________
linuxtools-dev mailing list
linuxtools-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
