Re: [linuxtools-dev] Gcov and Gprof plugins

[xraynaud <xraynaud@xxxxxxxxx>]

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
> linuxtools-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/linuxtools-dev