Android code coverage
catblade
unfortunately, we are getting this error (even when using the "special
for android" gcov): geninfo: ERROR: /storage/gcov/out/target/product/
kernel_build/drivers/power/battery.gcno: reached unexpected end of
file
I even have tried some minor hacking of geninfo, but then start
getting failures on the gcda files.
Anyone have some help they can provide? We are using gcc 4.2.1.
Best wishes,
catblade
Nikolai Kondrashov
> We are trying to instrument code coverage with gcov/lcov...
> unfortunately, we are getting this error (even when using the "special
> for android" gcov):
Are you talking about "special gcov", or "special lcov" here?
> geninfo: ERROR: /storage/gcov/out/target/product/
> kernel_build/drivers/power/battery.gcno: reached unexpected end of
> file
>
> I even have tried some minor hacking of geninfo, but then start
> getting failures on the gcda files.
>
> Anyone have some help they can provide? We are using gcc 4.2.1.
We have gcc 4.4.3 working, with hacks applied in some cases. Does collecting
coverage of a simple "Hello, world!" program work?
Sincerely,
Nick
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
Marlow Weston
On Dec 16, 2011 3:34 AM, "Nikolai Kondrashov" <nkond...@nvidia.com> wrote:
>
> On 12/15/2011 12:44 AM, catblade wrote:
>>
>> We are trying to instrument code coverage with gcov/lcov...
>> unfortunately, we are getting this error (even when using the "special
>> for android" gcov):
>
>
> Are you talking about "special gcov", or "special lcov" here?
Yes.
>
>> geninfo: ERROR: /storage/gcov/out/target/product/
>> kernel_build/drivers/power/battery.gcno: reached unexpected end of
>> file
>>
>> I even have tried some minor hacking of geninfo, but then start
>> getting failures on the gcda files.
>>
>> Anyone have some help they can provide? We are using gcc 4.2.1.
>
>
> We have gcc 4.4.3 working, with hacks applied in some cases. Does collecting
> coverage of a simple "Hello, world!" program work?
We have instrumented kernel gcov. I have not managed to get gcov for regular apps to work, even when setting GCOV_DEFAULT_PATH and GCOV_STRIP_PATH to both 123 and 4. I had looked into running lcov with --gcov-tools and playing with specialty chips, starting with ARM and moving to x86 specifically if one existed, but kept getting errors where I needed to specify an option of -c et cetera even though I was specifying -c.
I suspect this problem has to do with the non-standard architecture I am running on. Is there some documentation on how lcov and gcov work? I am assuming gcno is a dictionary file to decode gcda and if I knew where to look and what to expect, could fix it easily enough.
Nikolai Kondrashov
> > Are you talking about "special gcov", or "special lcov" here?
>
> Yes.
OK, I assume you're talking about lcov here :)
> >> geninfo: ERROR: /storage/gcov/out/target/product/
> >> kernel_build/drivers/power/battery.gcno: reached unexpected end of
> >> file
> >>
> >> I even have tried some minor hacking of geninfo, but then start
> >> getting failures on the gcda files.
> >>
> >> Anyone have some help they can provide? We are using gcc 4.2.1.
> >
> >
> > We have gcc 4.4.3 working, with hacks applied in some cases. Does collecting
> > coverage of a simple "Hello, world!" program work?
>
> We have instrumented kernel gcov.
What architecture are you using? Which kernel version? Did you apply any
patches to the kernel to make it work?
> I have not managed to get gcov for regular apps to work, even when setting
> GCOV_DEFAULT_PATH and GCOV_STRIP_PATH to both 123 and 4.
These environment variables only affect output file path modification and
there are no magic numbers that make it work, the variables are pretty
straightforward.
> I had looked into running lcov with
> --gcov-tools and playing with specialty chips, starting with ARM and
> moving to x86 specifically if one existed, but kept getting errors where I
> needed to specify an option of -c et cetera even though I was specifying
> -c.
You should use --gcov-tool option to specify the gcov tool belonging to the
toolchain you used to build the kernel.
> I suspect this problem has to do with the non-standard architecture I am
> running on. Is there some documentation on how lcov and gcov work? I am
> assuming gcno is a dictionary file to decode gcda and if I knew where to
> look and what to expect, could fix it easily enough.
You should compare what the kernel does in kernel/gcov/* to what the
gcc toolchain does in gcc/*gcov*.
The problem is that kernel doesn't use libgcov, it uses its own code to
generate .gcda files, so there could be mismatches in the file format. It
also expects specific instrumentation done to its sources by the compiler.
So, if there is any mismatch it wouldn't work and you should probably modify
the kernel.
You should try to make basic gcov summary output work first and only then
switch to making lcov work.
The fact that you weren't able to process userspace coverage output hints at
that lcov doesn't agree with gcov output format.
Marlow Weston
On 12/16/2011 03:02 PM, Marlow Weston wrote:OK, I assume you're talking about lcov here :)
> Are you talking about "special gcov", or "special lcov" here?
Yes.
ARGH! You are correct.
What architecture are you using? Which kernel version? Did you apply any
>> geninfo: ERROR: /storage/gcov/out/target/product/
>> kernel_build/drivers/power/battery.gcno: reached unexpected end of
>> file
>>
>> I even have tried some minor hacking of geninfo, but then start
>> getting failures on the gcda files.
>>
>> Anyone have some help they can provide? We are using gcc 4.2.1.
>
>
> We have gcc 4.4.3 working, with hacks applied in some cases. Does collecting
> coverage of a simple "Hello, world!" program work?
We have instrumented kernel gcov.
patches to the kernel to make it work?
Yes, we did apply patches. Kernel version 2.6.28. Architecture is a 32 bit x86 chip.
These environment variables only affect output file path modification and
I have not managed to get gcov for regular apps to work, even when setting
GCOV_DEFAULT_PATH and GCOV_STRIP_PATH to both 123 and 4.
there are no magic numbers that make it work, the variables are pretty
straightforward.
That is what I thought. Anyway, I am still getting no files showing up, so I am not sure what is going on there. If you have any insight, I would really appreciate it.
You should use --gcov-tool option to specify the gcov tool belonging to the
I had looked into running lcov with
--gcov-tools and playing with specialty chips, starting with ARM and
moving to x86 specifically if one existed, but kept getting errors where I
needed to specify an option of -c et cetera even though I was specifying
-c.
toolchain you used to build the kernel.
Right. The problem is, when I do that, I get errors that I need to specify -c, --diff, -z, et cetera. I have tried the example line you posted to another similar question in august and every permutation I can think of, and it patiently tells me I need to specify -c, -diff, or such.
You should compare what the kernel does in kernel/gcov/* to what the
I suspect this problem has to do with the non-standard architecture I am
running on. Is there some documentation on how lcov and gcov work? I am
assuming gcno is a dictionary file to decode gcda and if I knew where to
look and what to expect, could fix it easily enough.
gcc toolchain does in gcc/*gcov*.
Okay. Now we are getting somewhere.
The problem is that kernel doesn't use libgcov, it uses its own code to
generate .gcda files, so there could be mismatches in the file format. It
also expects specific instrumentation done to its sources by the compiler.
So, if there is any mismatch it wouldn't work and you should probably modify
the kernel.
Aha! Thank you. Now I know there to look.
You should try to make basic gcov summary output work first and only then
switch to making lcov work.
See above. I seem to be failing at that, as no files end up generated.
The fact that you weren't able to process userspace coverage output hints at
that lcov doesn't agree with gcov output format.
I agree.