On Thu, Jun 15, 2023 at 07:39:08PM +0900, Masahiro Yamada wrote:
> On Thu, Jun 15, 2023 at 6:54 PM Peter Oberparleiter
> <oberpar@xxxxxxxxxxxxx> wrote:
> >
> > On 13.06.2023 20:22, Kent Overstreet wrote:
> > > On Mon, Jun 12, 2023 at 06:18:35PM +0200, Peter Oberparleiter wrote:
> > >> I'm unaware of any kbuild support for setting GCOV_PROFILE for a
> > >> specific sub-directory from the command line, only from within the
> > >> associated Makefile. I'm not sure how this could have worked in the past
> > >> with the provide sample command line.
> > >>
> > >> Here's how GCOV_PROFILE evaluation works (from scripts/Makefile.lib):
> > >>
> > >> ifeq ($(CONFIG_GCOV_KERNEL),y)
> > >> _c_flags += $(if $(patsubst n%,, \
> > >> $(GCOV_PROFILE_$(basetarget).o)$(GCOV_PROFILE)$(CONFIG_GCOV_PROFILE_ALL)),\
> > >> $(CFLAGS_GCOV))
> > >> endif
> > >>
> > >> This bit of Makefile code determines whether to add the flags needed to
> > >> enabled gcov profiling (CFLAGS_GCOV) to the compiler flags for the
> > >> current compilation unit (_c_flags) by looking at the concatenation of
> > >> the following variables:
> > >>
> > >> - GCOV_PROFILE_<target base name>.o
> > >> - GCOV_PROFILE
> > >> - CONFIG_GCOV_PROFILE_ALL
> > >>
> > >> gcov flags are only added if this concatenation does not start with an
> > >> "n", and at least one of these variables is set to a non-empty value
> > >> other than "n" ("y" typically). The "starts with" part is required to
> > >> enable precedence for the more specific variable, e.g. an "n" in
> > >> GCOV_PROFILE_filename.o overwrites a "y" in GCOV_PROFILE.
> > >>
> > >> As you can see, there is no reference to a GCOV_PROFILE variable that is
> > >> named after the sub-directory for which profiling should be enabled.
> > >
> > > I've been digging through the git history, and I would swear I
> > > hallucinated the whole thing except I have the code in ktest for driving
> > > gcov and I swear it used to work :)
> > >
> > > Anyways - any thoughts on how we might implement this? I really need a
> > > way to specify directories to enable gcov for _without_ monkey patching;
> > > that's not a viable workflow in an automated setup.
> > >
> > > It seems like if we can get a list of directory prefixes for a path
> > > (e.g. given fs/bcachefs/btree_iter.o it would return fs, fs/bcachefs) it
> > > should be possible to extend the code you referenced.
> >
> > I'll likely not be able to implement this myself, but if you or anyone
> > else wants to go that route, here are my thoughts: $(src) should have
> > the relative source code path that is needed, so here's what needs to be
> > done:
> >
> > 1. Determine how to handle non-letter/digit/underscore characters in the
> > variable name:
> >
> > a) GCOV_PROFILE_fs/bcachefs => supported by GNU make [1], though
> > discouraged due to possible side-effects
> > b) GCOV_PROFILE_fs_bcachefs => might cause overlays, e.g. a/b/c and
> > a/b_c both have the same a_b_c suffix
> >
> > Personally I'd prefer option b)
> >
> > 2. Define a new Makefile variable that contains $(src) with required
> > character replacements (scripts/Kbuild.include might be a good place)
> >
> > 3. Add $(GCOV_PROFILE_$(name_of_that_new_var)) to the code quoted above
> > (scripts/Makefile.lib)
> >
> > 4. Document the use of this new Makefile variable in kernel/gcov/Kconfig
> > and Documentation/dev-tools/gcov.rst
> >
> > Since this new path-suffix version would be the first
> > GCOV_PROFILE-variable that is primarily intended to be specified on the
> > make command line and not added to a Makefile, it should probably take
> > precedence over all other versions. To achieve that it would need to be
> > specified first in the $(patsubst) statement.
> >
> > Once implemented, one might also consider extending this new support to
> > other variables like KASAN_SANITIZE or KCOV_INSTRUMENT, since all of
> > these are implemented the same way. I don't know whether that's useful
> > in all cases though.
> >
> > [1] https://www.gnu.org/software/make/manual/make.html#Using-Variables
> >
> > --
> > Peter Oberparleiter
> > Linux on IBM Z Development - IBM Germany R&D
> >
>
>
> I do not think it is a sensible proposal.
>
> Another idea could be something like
> CONFIG_GCOV_PROFILE_PATH=fs/bcachefs
With that it would only be possible to enable profiling for a single
subdirectory, and that's not going to be enough; when doing code
coverage analysis of a module we may want to profile library code/other
modules it depends on.
> or isn't it possible to filter dynamically?
> I think ftrace can change filtering dynamically.
> I do not know if it is possible for GCOV because I do not use it.
gcov requires different build flags, so no, not possible.
