| Re: [linuxtools-dev] Gcov and Gprof plugins |
Hi all, For the history of ST-Gprof and ST-Gcov: In fact, Renato's proposal was studied in the early specs ;and at that time, the chosen solution was to parse the profiling data files (gmon.out /*.gcno /*.gcda) by the plugin itself without using an external program for the following reasons: - More precision in results: in ST-Gprof, we adjust the time unit (sec/milli-sec/micro-sec) of each column according to the values, while with Gprof values are null (time units chosen for the columns of a Flat Profile results are sec/milli-sec even for very small samples (in micro-sec) - Better performance: for large projects, we found that for ST-Gcov it was heavy to call the utility Gcov and parse its output from temporary files as many times as a source files in the project By the way, in the plugin ST-Gprof, we do call the binutils gprof executable with “-sum” option to perform the aggregation of results Lilia -----Original Message----- 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 <jjohnstn@xxxxxxxxxx> 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@xxxxxxxxxxx >>>> https://dev.eclipse.org/mailman/listinfo/linuxtools-dev >> > > _______________________________________________ > linuxtools-dev mailing list |