On Thu, Mar 11, 2021 at 5:07 AM Peter Oberparleiter <ober...@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