lkml.org 
[lkml]   [2009]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: gcov: enable GCOV_PROFILE_ALL for x86_64
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.



\
 
 \ /
  Last update: 2009-06-23 09:45    [W:0.217 / U:0.360 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site