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
