Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1467543

Re: linux-next: build warnings after merge of the kbuild tree

From Nicholas Piggin <npiggin@gmail.com>
Newsgroups linux.kernel
Subject Re: linux-next: build warnings after merge of the kbuild tree
Date 2016-08-22 12:50 +0200
Message-ID <s8UXL-5aa-9@gated-at.bofh.it> (permalink)
References (2 earlier) <s7k9X-TX-5@gated-at.bofh.it> <s7IYF-kP-11@gated-at.bofh.it> <s7KnM-1nF-11@gated-at.bofh.it> <s7Nvj-3hy-9@gated-at.bofh.it> <s7PGN-4yC-7@gated-at.bofh.it>
Organization IBM

Show all headers | View raw


On Fri, 19 Aug 2016 20:44:55 +1000
Nicholas Piggin <npiggin@gmail.com> wrote:

> On Fri, 19 Aug 2016 10:37:00 +0200
> Michal Marek <mmarek@suse.cz> wrote:
> 
> > On 2016-08-19 07:09, Stephen Rothwell wrote:  

[snip]

> > > 
> > > I may be missing something, but genksyms generates the crc's off the
> > > preprocessed C source code and we don't have any for the asm files ...    
> > 
> > Of course you are right. Which means that we are losing type information
> > for these exports for CONFIG_MODVERSIONS purposes. I guess it's
> > acceptable, since the asm functions are pretty basic and their
> > signatures do not change.  
> 
> I don't completely agree. It would be nice to have the functionality
> still there.
> 
> What happens if you just run cmd_modversions on the as rule? It relies on
> !defined(__ASSEMBLY__), but we're feeding the result to genksyms, not as.
> It would require the header be included in the .S file and be protected for
> asm builds.


This seems like it *could* be made to work, but there's a few problems.

- .h files are not made for C consumption. Matter of manually adding the
ifdef guards, which isn't terrible.

- .S files do not all include their .h where the C declaration is. Also
will cause some churn but doable and maybe not completely unreasonable.

- genksyms parser barfs when it hits the assembly of the .S file. Best
way to fix that seems just send the #include and EXPORT_SYMBOL lines
from the .S to the preprocessor. That's a bit of a rabbit hole too, with
some .S files being included, etc.

I'm not sure what to do here. If nobody cares and we lose CRCs for .S
exports, then okay we can whitelist those relocs easily. If we don't want
to lose the functionality, the above might work but it's a bit intrusive
an is going to require another cycle of prep patches to go through arch
code first.

Or suggestions for alternative approach?

Thanks,
Nick

Back to linux.kernel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

linux-next: build warnings after merge of the kbuild tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-08-17 03:50 +0200
  Re: linux-next: build warnings after merge of the kbuild tree Michal Marek <mmarek@suse.cz> - 2016-08-17 15:10 +0200
    Re: linux-next: build warnings after merge of the kbuild tree Nicholas Piggin <npiggin@gmail.com> - 2016-08-18 03:20 +0200
      Re: linux-next: build warnings after merge of the kbuild tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-08-19 05:50 +0200
        Re: linux-next: build warnings after merge of the kbuild tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-08-19 07:20 +0200
          Re: linux-next: build warnings after merge of the kbuild tree Nicholas Piggin <npiggin@gmail.com> - 2016-08-19 07:40 +0200
          Re: linux-next: build warnings after merge of the kbuild tree Michal Marek <mmarek@suse.cz> - 2016-08-19 10:40 +0200
            Re: linux-next: build warnings after merge of the kbuild tree Nicholas Piggin <npiggin@gmail.com> - 2016-08-19 13:00 +0200
              Re: linux-next: build warnings after merge of the kbuild tree Nicholas Piggin <npiggin@gmail.com> - 2016-08-22 12:50 +0200

csiph-web