[Intel-gfx] [PATCH] drm/i915: Enable fine-grained kcov instrumentation

[Chris Wilson]

On Thu, Aug 04, 2016 at 02:49:17PM +0300, Joonas Lahtinen wrote:
> On to, 2016-08-04 at 07:30 +0100, Chris Wilson wrote:
> > On Thu, Aug 04, 2016 at 09:12:07AM +0300, Joonas Lahtinen wrote:
> > > 
> > > On ke, 2016-08-03 at 20:38 +0100, Chris Wilson wrote:
> > > > 
> > > > In the next merge, we can build support for kcov at the individual file,
> > > > or driver level. This is useful to filter out the noise when doing
> > > > coverage test, i.e. we do get edges through code outside of i915.ko.
> > > > 
> > > > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > > Umm, is not KCOV enabled by selecting KCOV and then instrumentation is
> > > only disabled on select objects? "KCOV_INSTRUMENT_foo.o := n"?
> > commit a4691deabf284a601149a067525759939cc563b2
> > Author: Vegard Nossum <vegard.nossum at oracle.com>
> > Date:   Tue Aug 2 14:07:30 2016 -0700
> > 
> >     kcov: allow more fine-grained coverage instrumentation
> >     
> >     For more targeted fuzzing, it's better to disable kernel-wide
> >     instrumentation and instead enable it on a per-subsystem basis.  This
> >     follows the pattern of UBSAN and allows you to compile in the kcov
> >     driver without instrumenting the whole kernel.
> >     
> >     To instrument a part of the kernel, you can use either
> >     
> >         # for a single file in the current directory
> >         KCOV_INSTRUMENT_filename.o := y
> >     
> >     or
> >     
> >         # for all the files in the current directory (excluding subdirectories)
> >         KCOV_INSTRUMENT := y
> >     
> >     or
> >     
> >         # (same as above)
> >         ccflags-y += $(CFLAGS_KCOV)
> >     
> >     or
> >     
> >         # for all the files in the current directory (including subdirectories)
> >         subdir-ccflags-y += $(CFLAGS_KCOV)
> > 
> > 
> > The commit itself adds KCOV_INSTRUMENT_ALL config target to enable
> > kernel-wide coverage, with KCOV then just enabling the debug interface.
> 
> Could reference the patch in commit message if you especially want this
> reviewed upfront. I see it could be merged after we get the commit to
> our tree, too.

Not expecting anything before we get our backmerge. Just found it
interesting when going over the delta from Linus.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre