From: Dodji Seketeli <dodji@seketeli.org>
To: Nicholas Piggin <npiggin@gmail.com>
Cc: Ian Campbell <ijc@hellion.org.uk>, Michal Marek <mmarek@suse.com>,
Ben Hutchings <ben@decadent.org.uk>,
Linus Torvalds <torvalds@linux-foundation.org>,
Adam Borowski <kilobyte@angband.pl>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
Debian kernel maintainers <debian-kernel@lists.debian.org>,
"linux-arch\@vger.kernel.org" <linux-arch@vger.kernel.org>,
Arnd Bergmann <arnd@arndb.de>, Ingo Molnar <mingo@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm
Date: Fri, 09 Dec 2016 23:46:54 +0100 [thread overview]
Message-ID: <86vaus3eld.fsf@seketeli.org> (raw)
In-Reply-To: <20161210021529.4a6e684f@roar.ozlabs.ibm.com> (Nicholas Piggin's message of "Sat, 10 Dec 2016 02:15:29 +1000")
Hello,
Nicholas Piggin <npiggin@gmail.com> 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
[suppress_type]
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?
[1]: https://sourceware.org/libabigail/manual/abidiff.html
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 https://sourceware.org/git/?p=libabigail.git;a=summary
Cheers,
--
Dodji
WARNING: multiple messages have this Message-ID (diff)
From: Dodji Seketeli <dodji@seketeli.org>
To: Nicholas Piggin <npiggin@gmail.com>
Cc: Ian Campbell <ijc@hellion.org.uk>, Michal Marek <mmarek@suse.com>,
Ben Hutchings <ben@decadent.org.uk>,
Linus Torvalds <torvalds@linux-foundation.org>,
Adam Borowski <kilobyte@angband.pl>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
Debian kernel maintainers <debian-kernel@lists.debian.org>,
"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
Arnd Bergmann <arnd@arndb.de>, Ingo Molnar <mingo@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm
Date: Fri, 09 Dec 2016 23:46:54 +0100 [thread overview]
Message-ID: <86vaus3eld.fsf@seketeli.org> (raw)
In-Reply-To: <20161210021529.4a6e684f@roar.ozlabs.ibm.com> (Nicholas Piggin's message of "Sat, 10 Dec 2016 02:15:29 +1000")
Hello,
Nicholas Piggin <npiggin@gmail.com> 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
[suppress_type]
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?
[1]: https://sourceware.org/libabigail/manual/abidiff.html
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 https://sourceware.org/git/?p=libabigail.git;a=summary
Cheers,
--
Dodji
next prev parent reply other threads:[~2016-12-09 22:56 UTC|newest]
Thread overview: 124+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <a73aec83-ddad-2bdf-e612-178c9936a16f@manjaro.org>
[not found] ` <20161102004639.6870806d@roar.ozlabs.ibm.com>
2016-11-23 20:08 ` BUG: 4.9-rc6 Still "no symbol version" on boot Philip Müller
2016-11-23 20:14 ` Robert LeBlanc
2016-11-23 20:27 ` Philip Müller
2016-11-23 20:53 ` Adam Borowski
2016-11-23 21:01 ` Robert LeBlanc
2016-11-23 21:02 ` [PATCH] x86/kbuild: enable modversions for symbols exported from asm Adam Borowski
2016-11-23 23:10 ` Philip Müller
2016-11-24 4:40 ` Ingo Molnar
2016-11-24 5:20 ` Nicholas Piggin
2016-11-24 6:00 ` Ingo Molnar
2016-11-24 7:20 ` Nicholas Piggin
2016-11-24 7:36 ` Greg Kroah-Hartman
2016-11-24 7:53 ` Nicholas Piggin
2016-11-24 9:32 ` Michal Marek
2016-11-24 10:03 ` Nicholas Piggin
2016-11-24 10:51 ` Michal Marek
2016-11-24 9:38 ` Arnd Bergmann
2016-11-24 10:01 ` Nicholas Piggin
2016-11-24 9:56 ` Greg Kroah-Hartman
2016-11-24 10:31 ` Nicholas Piggin
2016-11-24 15:24 ` Greg Kroah-Hartman
2016-11-25 0:40 ` Nicholas Piggin
2016-11-25 18:00 ` Linus Torvalds
2016-11-26 0:37 ` Nicholas Piggin
2016-11-29 1:15 ` Ben Hutchings
2016-11-29 2:31 ` Nicholas Piggin
2016-11-29 9:14 ` Michal Marek
2016-11-29 4:08 ` Linus Torvalds
2016-11-29 13:19 ` Adam Borowski
2016-11-29 13:29 ` Ingo Molnar
2016-11-29 14:24 ` Adam Borowski
2016-11-29 13:51 ` Adam Borowski
2016-11-29 15:27 ` Linus Torvalds
2016-11-29 16:03 ` Michal Marek
2016-11-29 16:17 ` Linus Torvalds
2016-11-29 19:57 ` Ben Hutchings
2016-11-29 20:35 ` Linus Torvalds
2016-11-30 18:18 ` Nicholas Piggin
2016-11-30 18:40 ` Linus Torvalds
2016-11-30 21:33 ` Ben Hutchings
2016-12-01 1:55 ` Nicholas Piggin
2016-12-01 2:35 ` Ben Hutchings
2016-12-01 3:39 ` Nicholas Piggin
2016-12-01 16:12 ` Michal Marek
2016-12-02 14:36 ` Hannes Frederic Sowa
2016-12-09 3:33 ` Nicholas Piggin
2016-12-09 15:21 ` Ian Campbell
2016-12-09 16:15 ` Nicholas Piggin
2016-12-09 22:46 ` Dodji Seketeli [this message]
2016-12-09 22:46 ` Dodji Seketeli
2016-12-10 12:41 ` Greg Kroah-Hartman
2016-12-12 3:50 ` Nicholas Piggin
2016-12-12 9:08 ` Ian Campbell
2016-12-14 17:59 ` Don Zickus
2016-12-13 1:07 ` Stanislav Kozina
2016-12-13 22:51 ` Michal Marek
2016-12-14 8:58 ` Dodji Seketeli
2016-12-14 8:58 ` Dodji Seketeli
2016-12-14 9:15 ` Michal Marek
2016-12-14 9:36 ` Dodji Seketeli
2016-12-14 9:36 ` Dodji Seketeli
2016-12-14 9:44 ` Michal Marek
2016-12-14 10:02 ` Dodji Seketeli
2016-12-14 10:02 ` Dodji Seketeli
2016-12-14 10:15 ` Michal Marek
2016-12-14 9:56 ` Dodji Seketeli
2016-12-14 9:56 ` Dodji Seketeli
2016-12-14 9:37 ` Michal Marek
2016-12-01 4:13 ` Don Zickus
2016-12-01 4:32 ` Nicholas Piggin
2016-12-01 15:20 ` Don Zickus
2016-12-01 15:26 ` Christoph Hellwig
2016-12-01 15:40 ` Don Zickus
2016-12-01 16:06 ` Greg Kroah-Hartman
2016-12-01 18:42 ` Don Zickus
2016-12-09 3:50 ` Nicholas Piggin
2016-12-09 7:55 ` Stanislav Kozina
2016-12-09 8:14 ` Nicholas Piggin
2016-12-09 14:36 ` Stanislav Kozina
2016-12-09 15:56 ` Nicholas Piggin
2016-12-09 16:03 ` Greg Kroah-Hartman
2016-12-12 9:48 ` Stanislav Kozina
2016-12-13 7:25 ` Nicholas Piggin
2016-12-14 14:04 ` Hannes Frederic Sowa
2016-12-15 2:06 ` Nicholas Piggin
2016-12-15 11:19 ` Hannes Frederic Sowa
2016-12-15 12:03 ` Nicholas Piggin
2016-12-15 13:15 ` Hannes Frederic Sowa
2016-12-15 14:15 ` Nicholas Piggin
2016-12-15 15:17 ` Hannes Frederic Sowa
2016-12-15 13:35 ` Stanislav Kozina
2016-12-09 16:16 ` Don Zickus
2016-12-01 10:48 ` Stanislav Kozina
2016-12-01 11:09 ` Nicholas Piggin
2016-12-01 11:33 ` Stanislav Kozina
2016-12-01 12:39 ` Nicholas Piggin
2016-12-01 15:19 ` Dodji Seketeli
2016-12-01 15:19 ` Dodji Seketeli
2016-12-01 15:19 ` Dodji Seketeli
2016-12-01 15:19 ` Dodji Seketeli
2016-12-01 16:14 ` Michal Marek
2016-11-29 17:05 ` Adam Borowski
2016-11-29 17:05 ` Adam Borowski
2016-11-29 17:10 ` Linus Torvalds
2016-11-29 17:14 ` Linus Torvalds
2016-12-01 13:58 ` Arnd Bergmann
2016-12-01 16:21 ` Michal Marek
2016-12-01 18:26 ` Linus Torvalds
2016-12-02 10:55 ` Arnd Bergmann
2016-12-02 12:40 ` [RFC, PATCH, v3.9] default exported asm symbols to zero Arnd Bergmann
2016-12-02 12:59 ` Geert Uytterhoeven
2016-12-02 14:51 ` Arnd Bergmann
2016-12-02 15:35 ` Adam Borowski
2016-12-02 15:35 ` Adam Borowski
2016-12-03 4:36 ` Ben Hutchings
2016-12-03 10:43 ` Arnd Bergmann
2016-12-02 17:04 ` [PATCH] x86/kbuild: enable modversions for symbols exported from asm Linus Torvalds
2016-12-04 7:44 ` Alan Modra
2016-12-04 20:44 ` Linus Torvalds
2016-11-29 21:23 ` Michal Marek
2016-11-24 9:25 ` Michal Marek
2016-11-24 11:42 ` Regression: " Kalle Valo
2016-11-23 23:07 ` BUG: 4.9-rc6 Still "no symbol version" on boot Philip Müller
2016-11-28 17:10 ` Robert LeBlanc
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86vaus3eld.fsf@seketeli.org \
--to=dodji@seketeli.org \
--cc=arnd@arndb.de \
--cc=ben@decadent.org.uk \
--cc=debian-kernel@lists.debian.org \
--cc=gregkh@linuxfoundation.org \
--cc=ijc@hellion.org.uk \
--cc=kilobyte@angband.pl \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=mmarek@suse.com \
--cc=npiggin@gmail.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.