[LLVMdev] GCC compatibility code coverage issue .

[Umesh Kalappa]

Thank you Justin  for clarification ,was meant better here , that
instrprof is less overahed w.r.t to binary size compare to gcc .

Thank you again.
~Umesh

On Wed, May 27, 2015 at 9:51 PM, Justin Bogner <mail at justinbogner.com> wrote:
> Umesh Kalappa <umesh.kalappa0 at gmail.com> writes:
>> Hi Justin ,
>>
>> Thank you for the confirmation and we would like to know that ,going
>> forward the clang has the support the gcc gcov format or use the
>> -fprofile-instr-generate -fcoverage-mapping  and get ride of gcov
>> format .
>
> Going forward, the -fprofile-instr-generate -fcoverage-mapping (which
> I'll refer to as instrprof) work will continue to be improved and built
> upon. The gcov support in llvm isn't going away, but it isn't likely to
> be improved or changed much at this point.
>
>> We are planing to customize the clang code coverage for embedded world
>> ,before we start tweaking the gcov / -fprofile-instr-generate
>> code-base ,we would like to take feedback from the group .
>>
>> Did -fprofile-instr-generate -fcoverage-mapping better than(optimized
>> instrumented) gcov ? ,if so any benchmark reference will be
>> appreciated.
>
> I'm not sure what you mean by better. The instrprof approach is more
> accurate and has significantly lower runtime overhead than the gcov
> support in llvm. It is also quite a bit simpler and more flexible in
> terms of data collection. It does currently have a pretty high overhead
> in terms of binary size, especially for coverage.
>
>> Thank you and awaiting for your suggestions.
>> ~Umesh
>>
>> On Wed, May 13, 2015 at 1:17 PM, Justin Bogner <mail at justinbogner.com> wrote:
>>> Yes, the fix for this is in the 3.6.1 release candidate.
>>>
>>>
>>> On Wednesday, May 13, 2015, Umesh Kalappa <umesh.kalappa0 at gmail.com> wrote:
>>>>
>>>> Hi Justin,
>>>>
>>>> How  you  doing there ?
>>>>
>>>> Do you able to fetch the changes w.r.t PR22436 to 4.6.1.
>>>>
>>>> Thank you
>>>> ~Umesh
>>>>
>>>> On Wed, Apr 29, 2015 at 7:42 PM, Justin Bogner <mail at justinbogner.com>
>>>> wrote:
>>>> > Oh, sorry, this is http://llvm.org/PR22436 which is fixed in trunk, but
>>>> > not
>>>> > in 3.6.0. I'll double-check / see about getting the fix in 3.6.1.
>>>> >
>>>> > On Tuesday, April 28, 2015, Umesh Kalappa <umesh.kalappa0 at gmail.com>
>>>> > wrote:
>>>> >>
>>>> >> Hi Justin ,
>>>> >>
>>>> >> Thank you for the reply,but without version too ,the llvm-cov fails i.e
>>>> >>
>>>> >> bash-4.1$ clang -fprofile-arcs -ftest-coverage test.c
>>>> >> bash-4.1$ ./a.out
>>>> >> bash-4.1$ llvm-cov gcov test.c
>>>> >> Unexpected number of edges (in main).
>>>> >> Invalid .gcda File!
>>>> >>
>>>> >> bash-4.1$ clang -g -O0 -fprofile-arcs -ftest-coverage -Xclang
>>>> >> -coverage-cfg-checksum -Xclang -coverage-no-function-names-in-data
>>>> >> test.c
>>>> >> bash-4.1$ ./a.out
>>>> >> bash-4.1$ llvm-cov gcov test.c
>>>> >> Unexpected end of memory buffer: 386832052.
>>>> >> Invalid .gcno File!
>>>> >>
>>>> >> bash-4.1$ clang -v
>>>> >> clang version 3.6.0 (tags/RELEASE_360/final)
>>>> >> Target: x86_64-unknown-linux-gnu
>>>> >> Thread model: posix
>>>> >>
>>>> >> Thank you
>>>> >> ~Umesh
>>>> >>
>>>> >> On Tue, Apr 28, 2015 at 8:32 PM, Justin Bogner
>>>> >> <justin at justinbogner.com>
>>>> >> wrote:
>>>> >> >
>>>> >> > On Tuesday, April 28, 2015, Umesh Kalappa <umesh.kalappa0 at gmail.com>
>>>> >> > wrote:
>>>> >> >>
>>>> >> >> Hi All,
>>>> >> >>
>>>> >> >> We trying  to use clang+llvm to generate the gcc  coverage format as
>>>> >> >>
>>>> >> >> clang version 3.6.0
>>>> >> >>
>>>> >> >> $clang  --coverage -Xclang -coverage-cfg-checksum -Xclang
>>>> >> >> -coverage-no-function-names-in-data -Xclang -coverage-version='407*'
>>>> >> >> test.c
>>>> >> >>
>>>> >> >> $a.out
>>>> >> >>
>>>> >> >> $llvm-cov gcov test.gcda
>>>> >> >>
>>>> >> >> Unexpected version: *704.
>>>> >> >> Invalid .gcno File!
>>>> >> >
>>>> >> >
>>>> >> > The llvm-cov tool supports the 402* format, which is what clang emits
>>>> >> > by
>>>> >> > default. If you remove the -Xclang arguments from your compilation it
>>>> >> > should
>>>> >> > work.
>>>> >> >
>>>> >> >>
>>>> >> >> Debugging the above cause ,But any hints from experts here ,will
>>>> >> >> help a
>>>> >> >> lot .
>>>> >> >>
>>>> >> >> Appreciate your time ,Thank you
>>>> >> >> ~Umesh
>>>> >> >> _______________________________________________
>>>> >> >> LLVM Developers mailing list
>>>> >> >> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>> >> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev