linux-kernel - Re: gcov: enable GCOV_PROFILE_ALL for x86

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4A408774.9010401@linux.vnet.ibm.com>
Date:	Tue, 23 Jun 2009 09:42:44 +0200
From:	Peter Oberparleiter <oberpar@...ux.vnet.ibm.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/