Messages in this thread | | | Date | Tue, 23 Jun 2009 09:42:44 +0200 | From | Peter Oberparleiter <> | Subject | Re: 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.
| |