[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [linuxtools-dev] Gcov and Gprof plugins
|
On Mon, 2012-06-18 at 17:09 -0400, Jeff Johnston wrote:
> 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).
>
Ok, I understand the difference, but what I really meant is, instead of
parsing gmon.out as it is currently done, why not call binutils gprof
executable in the command line with proper arguments and then parse
OUTFILE ?
$ gprof OPTIONS [EXECUTABLE-FILE [PROFILE-DATA-FILES...]] [> OUTFILE]
> 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.
>
Renato
> 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
>