Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210311130328.2859337-1-oberpar@linux.ibm.com>
In-Reply-To: <20210311130328.2859337-1-oberpar@linux.ibm.com>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu, 11 Mar 2021 10:38:51 -0800
Message-ID: <CAHk-=whmwT-_VJJ72C1Wyzbzb_rRb9c7bc5RpGhdOXsyz4FDKQ@mail.gmail.com>
Subject: Re: [PATCH] gcov: fail build on gcov_info size mismatch
To:     Peter Oberparleiter <oberpar@linux.ibm.com>
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, Mar 11, 2021 at 5:07 AM Peter Oberparleiter
<oberpar@linux.ibm.com> wrote:
>
> This patch adds a compile-time check to ensure that the kernel's version
> of struct gcov_info has the same length as the one used by GCC as
> determined by looking at GCC's assembler output.

So I don't think this is a bad idea, but if you end up test-compiling
something, could we not verify things a bit more?

If you actually build the object file, you should be able to then
check much more. You'll find the pointer to the struct gcov_info in
"__gcov_.fn", which is admittedly hard to then link against a test
program (because of that dot in the name that means that you can't
even use "attribute((alias..))" to generate some other name for it).

But then you could test not only the size, but you could verify that
the "filename" field matches, that the n_functions field should be 1
etc.

IOW, it feels like some ELF munging (possibly even with just scripting
with "objdump") should be able to add verification for a bit more than
just the size.

I guess the size is kind of critical, because of how GCOV_COUNTERS has
changed, but if any other layout issue changes, the size might not be
all that relevant.

For example, looking at the current "struct gcov_info" gcc uses, it's
very badly packed, with 32-bit fields literally interspersed with
64-bit fields. So I could easily imagine that somebody goes "heyt,
guys, we need to add another GCOV counter, but we don't need to change
the size of the gcov_info, because we can just out the "version" and
"stamp" integers next to each other and getting rid of the padding
makes up for the extra counter".

I dunno. The gcov code has obviously never actually done anything like
this before, so maybe I'm just taking the "we could verify
_something_" and my reaction is that there could be even more
verification if we really want to go down that rabbit hole..

           Linus