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

[Nicholas Piggin]

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

> On Fri, 19 Aug 2016 10:37:00 +0200
> Michal Marek <mmarek@xxxxxxx> 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