On Fri, Jun 17, 2016 at 05:46:38PM +0200, Alexander Potapenko wrote: > On Fri, Jun 17, 2016 at 5:42 PM, Kees Cook <keesc...@chromium.org> wrote: > > On Fri, Jun 17, 2016 at 2:39 AM, Mark Rutland <mark.rutl...@arm.com> wrote: > >> If the toolchain does not support -fsanitize-coverage=trace-pc, we blat > >> this option from CFLAGS_KCOV, and build the kernel without > >> instrumentation, even if CONFIG_KCOV was selected. However, we still > >> build the rest of the kcov infrastructure, and expose a kcov file under > >> debugfs. This can be confusing, as the kernel will appear to support > >> kcov, yet will never manage to sample any trace PC values. While we do > >> note this fact at build time, this may be missed, and a user may not > >> have access to build logs. > > > > Do you want to refuse to build if the compiler doesn't support the > > flag? I finally figured out how to do this, I think, for > > -fstack-protector: > > > > http://git.kernel.org/cgit/linux/kernel/git/kees/linux.git/commit/?h=kbuild/stackprotector&id=600c1bd5f8647a8470dc2fc5a8697e3eafb5fd52 > > > > If you wanted, the CONFIG_KCOV test could live under the same > > prepare-compiler-check target. > > > > -Kees > > > I suspect the intention here is not to abort the build, but to have an > opportunity to report at run time that the kernel has been built > without kcov support.
My concern was that it was easy to miss the build-time warning, and having the kcov file visible and accessible didn't make clear to the user that the feature won't actually work. I'm happy for a failed kcov_open or anything stronger than that (e.g. the kcov file not bring present, or the build being aborted). Thanks, Mark.