Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

From: Dodji Seketeli
Date: Fri Dec 09 2016 - 17:56:07 EST


Nicholas Piggin <npiggin@xxxxxxxxx> a Ãcrit:


> That said, a dwarf based checker tool should be able to do as good a job
> (maybe a bit better because report is very informative and it may pick up
> compiler alignments or padding options).

So, Nicholas was kind enough to send me the two Linux Kernel binaries
that he built with the tiny little interface change that we were
discussing earlier. Here is what the abidiff[1] tools says about that
interface change:

$ time ~/git/libabigail/kabidiff/build/tools/abidiff vmlinux.abi1.abi vmlinux.abi2.abi
Functions changes summary: 0 Removed, 1 Changed, 0 Added function
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable

1 function with some indirect sub-type change:

[C]'function int foo(blah*)' at memory.c:82:1 has some indirect sub-type changes:
parameter 1 of type 'blah*' has sub-type changes:
in pointed to type 'struct blah' at memory.c:78:1:
type size changed from 32 to 64 bits
1 data member insertion:
'int blah::y', at offset 0 (in bits) at memory.c:79:1
1 data member change:
'int blah::x' offset changed from 0 to 32 (in bits) (by +32 bits)

real 0m2.595s
user 0m2.489s
sys 0m0.108s

I kept the timing information to give you an idea of the time it takes
on a non-optimized build of abidiff.

One could for instance want that types that are not defined in header
files be kept out of the change report. In that case it's possible to
write a little suppression specification file like this one:

$ cat vmlinux.abignore
source_location_not_regexp = .*\\.h

You can then pass that suppression file to the tool:

$ ~/git/libabigail/kabidiff/build/tools/abidiff --suppr vmlinux.abignore vmlinux.abi1.abi vmlinux.abi2.abi
Functions changes summary: 0 Removed, 0 Changed (1 filtered out), 0 Added function
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable

real 0m2.574s
user 0m2.473s
sys 0m0.102s

So this is the kind of interface change analysis tool we are working on
at the moment.

One could also imagine a tool that would compute a CRC that takes the
very same suppression specification files into account, letting people
to decide that some interface changes are OK. That CRC would thus be
added to the special ELF sections we already have today. We could keep
the modversion machinery, but with a greater dose of flexibility.
Whenever modversion detects a change, abidiff would tell people what the
change is exactly.

What do you guys think?

Okay, the abidiff I used in this message is one that is not yet
released. It's source code is in the dodji/kabidiff branch of the
Git repository at;a=summary