Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933766AbcLIQPu (ORCPT ); Fri, 9 Dec 2016 11:15:50 -0500 Received: from mail-pg0-f68.google.com ([74.125.83.68]:35526 "EHLO mail-pg0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933088AbcLIQPr (ORCPT ); Fri, 9 Dec 2016 11:15:47 -0500 Date: Sat, 10 Dec 2016 02:15:29 +1000 From: Nicholas Piggin To: Ian Campbell Cc: Michal Marek , Ben Hutchings , Linus Torvalds , Adam Borowski , Greg Kroah-Hartman , Linux Kbuild mailing list , Debian kernel maintainers , "linux-arch@vger.kernel.org" , Arnd Bergmann , Ingo Molnar , Linux Kernel Mailing List , Dodji Seketeli Subject: Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm Message-ID: <20161210021529.4a6e684f@roar.ozlabs.ibm.com> In-Reply-To: <1481296893.4509.135.camel@hellion.org.uk> References: <20161129131922.GA31466@angband.pl> <20161129135118.24696-1-kilobyte@angband.pl> <30bb2db4-47bd-0c35-8328-ef032b551f06@suse.com> <20161129195721.GI2697@decadent.org.uk> <20161201051852.28dc335f@roar.ozlabs.ibm.com> <1480541581.16599.78.camel@decadent.org.uk> <20161201125545.406d092c@roar.ozlabs.ibm.com> <1480559754.16599.92.camel@decadent.org.uk> <20161201143928.07a08348@roar.ozlabs.ibm.com> <6e8cf20b-2d2f-ba1f-e02c-c757d5a25db7@suse.com> <20161209133308.0acbb57a@roar.ozlabs.ibm.com> <1481296893.4509.135.camel@hellion.org.uk> Organization: IBM X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2151 Lines: 71 On Fri, 09 Dec 2016 15:21:33 +0000 Ian Campbell wrote: > On Fri, 2016-12-09 at 13:33 +1000, Nicholas Piggin wrote: > >  > > Well I simply tested the outcome. If you have: > > > > struct blah { > >   int x; > > }; > > int foo(struct blah *blah) > > { > >   return blah->x; > > } > > EXPORT(foo); > > > > $ nm vmlinux | grep __crc_foo > > 00000000a0cf13a0 A __crc_foo > > > > Now change to > > > > struct blah { > >   int y; > >   int x; > > }; > > > > $ nm vmlinux | grep __crc_foo > > 00000000a0cf13a0 A __crc_foo > > > > It just doesn't catch these things. > > I found the same when I just added your snippet to init/main.c. > > _But_ when I moved the struct into include/types.h (which happened to > be included by init/main.c) then, with just x in the struct: > > $ make -s init/main.{o,symtypes} && grep -E foo\|blah init/main.symtypes && nm init/main.o  | grep __crc_foo > s#blah struct blah { int x ; }  > foo int foo ( s#blah * )  > 000000000cd0312e A __crc_foo > > but adding y: > > $ make -s init/main.{o,symtypes} && grep -E foo\|blah init/main.symtypes && nm init/main.o  | grep __crc_foo > s#blah struct blah { int x ; int y ; }  > foo int foo ( s#blah * )  > 00000000eda220c6 A __crc_foo > > So it does catch things in that case. > > With struct blah inline in main.c it was: > > $ make -s init/main.{o,symtypes} && grep -E foo\|blah init/main.symtypes && nm init/main.o  | grep __crc_foo > s#blah struct blah { UNKNOWN }  > foo int foo ( s#blah * )  > 00000000a0cf13a0 A __crc_foo > > So I suppose it only cares about structs which are in headers, which I > guess makes sense. I think it is working in at least one of the > important cases. Aha thanks, well that's my mistake. Clever little bugger, isn't it? Okay it's not so useless as I first thought! 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 I still think it's worth looking at those if we can remove modversions. Thanks, Nick