Re: [PATCH -rc v1] gcov: Disable gcov build with GCC 10

[Peter Oberparleiter]

(Adding GCC's gcov maintainer Martin Liška)

On 10.09.2020 21:18, Linus Torvalds wrote:
> On Thu, Sep 10, 2020 at 5:52 AM Peter Oberparleiter
> <oberpar@xxxxxxxxxxxxx> wrote:
>>
>> Fix this by updating the in-kernel GCOV_COUNTERS value. Also re-enable
>> config GCOV_KERNEL for use with GCC 10.
> 
> Lovely.
> 
> Is there some way we could see this value automatically, or at least
> have a check for it? Right now it's that _very_ magical number that
> depends on a gcc version in odd and undocumented ways..

I don't think there is, except for maybe parsing GCC debuginfo files
which I would consider an extreme prereq for compiling a kernel with
gcov support. Also GCOV_COUNTERS is only one part of the problem - any
change to struct gcov_info could have a similar effect.

> IOW - I'm assuming user space gcov infrastructure finds this number
> some way, and wondering if we couldn't do the same?
> 
> Or is the gcov tool itself just doing the same kind of thing, and
> having magic numbers?

Short answer: GCC compiles this number into GCC and the associated GCC
library and requires that only matching versions are used. The gcov_info
definition is not available outside the GCC source tree.

Longer answer:

When GCC is called to compile a program with coverage profiling support
it adds inline profiling code and data to the resulting assembler
output. This profiling code updates in-memory counters during program
execution and calls GCC library functions (libgcov) to - among other
things - register the gcov_info data and to write out the resulting data
file when the program terminates. The gcov tool consumes this data file
format, which is different from the in-memory gcov_info data.

The gcov kernel support emulates portions of libgcov - it receives the
gcov_info struct during initial registration, and creates a gcov data
file in debugfs for consumption by the gcov tool.

> I get the feeling that somebody who knows gcov would go "You are just
> doing this all completely incorrectly, you should do XYZ" when they
> see that GCOV_COUNTERS thing.

@Martin: would you care to comment from a GCC point of view?

> Maybe just a script that finds the right header file in the gcc
> installation and extracts it from there, if only to verify the magic
> number that we have?

The next best thing that comes to my mind would be a build-time script
that checks the size of the gcov_info struct generated by GCC and
compare that to the size of the kernel's gcov_info for that GCC version
(by parsing assembler output). This could catch some common classes of
changes to gcov_info, while not restricting usage of gcov kernel support
too much when gcov_info doesn't change (as was the case e.g. between GCC
7 and 9).

The "next worst thing" would be to disable CONFIG_GCOV_KERNEL for
unknown GCC versions until someone tests it and updates the associated
Kconfig file. This catches all changes, but at the cost of possibly
unnecessarily restricting GCC versions plus requiring regular
gcov-kernel updates.


-- 
Peter Oberparleiter
Linux on Z Development - IBM Germany