Re: gcov: enable GCOV_PROFILE_ALL for x86_64

[Peter Oberparleiter <oberpar@linux.vnet.ibm.com>]

Ingo Molnar wrote:
> the GCOV code cannot be enabled in distros right now, due to the 
> high compiler-generated overhead, and due to the fact that the gcov 
> data structures used are single threaded. (which makes a gcov 
> enabled kernel very slow on SMP, due to the global cacheline 
> bounces)

I definitely agree that the gcov kernel support shouldn't be active on 
distro kernels. In my opinion that is also not a strict requirement for 
code coverage testing. If you're only looking at the resulting overall 
coverage rate, than yes, having the mechanism active all the time would 
be a good thing. But the real use of code coverage testing lies in being 
able to look at what parts of the code are not hit by a test case. That 
requires preparation (getting the source) and focus on one kernel 
version. So in my opinion, the extra effort of building and installing 
the instrumented kernel is not a limiting factor.

> IMO it would be _much_ better to implement hardware-assisted 
> call-graph tracking:
> 
>  - Use the BTS (Branch Trace Store) facilities to hardware-sample 
>    all branches+calls (optionally, dynamically enable-able)
> 
>  - Post-process the raw branch trace information (in the kernel
>    BTS-overflow irq handler) to calculate call-coverage information.
> 
> Unlike the unconditional GCC based GCOV stuff that is currently 
> upstream, BTS tracing is supported by a large range of hardware and 
> it can be enabled _transparently_, so it could be built in and 
> enabled by distros too, to test code coverage.

This is a very interesting idea. You could get branch level coverage 
information out of this. Some open questions that I could think of:
* how to map branch addresses to source code lines
* how to determine how many branches there are during initialization to 
allocate enough resources

> Would you be interested in looking at (and implementing) this?

While it sounds tempting, I don't think that I can spare the time to 
effectively work on this, so I'll have to decline.