Hi, You're right, it makes sense.
It was not the way taken at the origin, but it can be changed. Note that at the origin , this plugin was developed in STMicroelectronics for a cross-development environment. Gprof and gcov plugins depends on cross-binutils to read the binary file. An extension point (located in plugin org.eclipse.linuxtools.binutils) was used to install cross-development tools support in eclipse. I add in copy the people on charge of this plugin at STMicroelectronics. Xavier On Tue, 19 Jun 2012 00:17:28 +0200, Jeff Johnston <jjohn...@redhat.com> wrote: > On 06/18/2012 05:39 PM, Renato Stoffalette Joao wrote: >> 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] > > Ah, sorry for the confusion. I think your suggestion makes perfect > sense in light of remote support and avoiding possible binary format > issues. I will leave it to Xavier to comment on this. > >> >>> 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@eclipse.org >>>> https://dev.eclipse.org/mailman/listinfo/linuxtools-dev >> > > _______________________________________________ > linuxtools-dev mailing list > linuxtools-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/linuxtools-dev _______________________________________________ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
